UK Government Department Still Runs VME Operating System Installed In 1974 189
Qedward writes: The UK government's Department for Work and Pensions is on the hunt for a new £135,000-a-year CTO, with part of their annual budget of £1 billion and responsibility for DWP's "digital transformation" to oversee the migration of the department's legacy systems which are still run on Fujitsu mainframes using the VME operating system installed in 1974.
Well, no one will hack in (Score:3)
Re: (Score:3, Informative)
If they can't, then they have no Google-Fu....
http://www.fujitsu.com/uk/services/application/application-development/vme/
Re: (Score:2)
superNOVA - that reminds me of Data General Nova [wikipedia.org].
Re: (Score:2)
If it's anything like my old Chevy Nova, it'll light up the night sky!
Modern Technology (Score:5, Interesting)
How many modern systems can anybody imagine still working and apparently doing what we need them to 40 years from now?
Re:Modern Technology (Score:4, Interesting)
Give me what that system cost in 1974 inflation adjusted dollars and I'll be happy to flip out a modern system every year. Using cheap less durable components with redundancy is a better strategy. I live in a 1830s house so I get the advantages of good quality construction. But if I were building a house I'd use 2014 cheap materials.
Re:Modern Technology (Score:5, Insightful)
Sorry, I'm calling complete and utter bullshit.
I've worked on enough legacy systems to know they didn't start off with some astronomical budget. They built it based on a set of requirements, coded it in house, and then it gradually expanded over many years of service.
Mainframe applications aren't sexy or glamorous, they're built on relatively simple interfaces, and slowly expand in scope over time.
They keep running because eventually they're woven into fabric of every other business process you have until they become something you can't trivially get rid of ... because every other damned thing relies on it even if it isn't obvious to the user. You end up having to replace everything
My experience with migrating from legacy apps says you'd churn out a half asses solution, which isn't compatible with the existing stuff, and which can't be made so, and which would eventually be abandoned as untenable.
You'd produce some solution which might be good if it didn't depend on throwing away every other system which touched this.
The vast majority of people who claim they could produce a functional replacement for legacy software in a short period of time have never been involved in that kind of process.
If it was easy, they'd have replaced it by now.
The problem with looking for a "track record of transitioning a large enterprise from ageing mainframe technologies to next generation web, social, mobile cloud, Big Data and deep learning technologies" is that it's a set of requirements written by idiots who don't want to replace the system, they want something completely different which will involve re-tooling everything else that touches this existing system.
Put your money where your mouth is, apply for the damned job.
Re: (Score:2)
This is something the federal government proves over and over again... The current tax code is a staggering collection of decades-old COBOL code, the air traffic control systems until very recently ran on vacuum tube computers, and the FBI has tried, and failed, repeatedly to transition off a
Re:Modern Technology (Score:5, Insightful)
Well, the problem happens when some technology evangelist or manager who doesn't know a damned thing about the existing system claims it's easy to migrate it to modern tools.
And neither the customer, nor the guy saying it's easy, has the barest clue about just how many other things depend on that system, and nobody can fully enumerate the functionality and corner cases.
And then you end up trying to shoe-horn a purpose built piece of software which has ran fine for decades into a modern paradigm, and realize you are failing utterly.
Because the modern tools usually simply can't accommodate all of the rules and logic in that system. They can't be cajoled into having enough flexibility, or simply can't do the same task.
People consistently underestimate just how well these systems do their job, and just how many little corner cases and integration points have been woven into them over the years. The platform is no longer elegant, or easy to explain, but it just keeps working. But dozens of other things rely on it, and if you change the underlying thing you rebuild everything else.
I've been on several projects trying to replace stuff built in the 60's and 70's -- and I wouldn't go near another one without very loudly saying how much risk is involved. Hell, even a system which has been around only since the 90s might be non-trivial to migrate away from -- precisely because in the 90s people were still building much more purpose-specific software.
It's a catch 22 ... they get increasingly difficult to maintain, but they sometimes are impossible to replace.
As I said, if it was easy to replace these systems, it would have been done already. Discovering just how difficult this can be has been the downfall of many a naive person who claims it's an easy thing to do.
Re: (Score:2)
I actually people on the IRS system. It isn't staggeringly complex it is moderately complex. They also have a lot of dysfunctional management, lack of proper skills, unclear budgeting all the way up, changing objectives, and unnecessary requirements all of which drive the costs sky high.
Re: (Score:2)
It certainly can be done. The problem is that it requires highly skilled developers committed to a multi-year, multi-phase project. It tends not to be done because management is rarely willing to commit to such a project and isn't willing to pay to have a full analysis and scope put together. No sane developer is going to be willing to do such a complex and detailed analysis for free up front knowing how likely it is that the paying work either won't get done or will be farmed out to code monkeys working fr
Re: (Score:2)
Yeah, ANYTHING is possible given enough talent, dedication and funding.
In reality though, even these multi-year, multi-phase implementations tend to go way over budget and fail to yield everything promised.
I've seen it happen, first-hand, when a company I worked for decided to implement a new ERP system and phase out a number of other applications and processes. They DID shell out the money to get the analysis done properly, but the problem really came in with ability for the new software to perform as inte
Re: (Score:3)
I and the GP were talking about the cost of the mainframe not the application layer at all.
As for legacy conversions click on my link I've done dozens of them and quite successfully. Absolutely capturing business rules is a big deal. And frankly most mainframe applications were labor inefficient in their construction. That doesn't mean $100m worth of programming can be replaced for $1m but it can be replaced for $10m.
Re: (Score:3)
That's a great point. The evolution of life has worked the same way. There are some proteins which are interacted with and depended on by so many other proteins that changing them would be catastrophic; I happened to be reading about tubulin and actin [nih.gov] today:
Re: (Score:2)
Re: (Score:2)
I think the GP was talking about the hardware. If not then on every Unix box there are routines still running from 1974. For example VI/VIM is an extension of ED (ED -> EX -> VI -> VIM) which is 1971.
Re:Modern Technology (Score:4, Informative)
Absolutely true. Today's structures will not stand the test of time. Even the concrete we use is steel reinforced which means in 2 centuries without ongoing care, it will be dust. Though Jerusalem where limestone is dirt cheap and still an excellent building material is an interesting counter example to that global trend towards throw away buildings.
Re: Modern Technology (Score:4, Insightful)
Re: (Score:3)
What I recently learned about is how asian temples at least in Korea are teared down and rebuilt every 20 years to 40 years (I don't remember and I don't know if it varies). Wooden parts fit together (no nails, bolts etc.)
There is not the western obsession with preserving extremely old buildings and parts of building in their original state for as long as possible, but instead cyclical continuity like the fable of the hammer whose head and handle were replaced mutiple times each.
Re:Modern Technology (Score:5, Insightful)
I am always amazed how buildings constructed thousands, or even hundreds, of years ago are still standing although often in a state of disrepair due to neglect
That's what's known as survivor bias. The only examples you see of thousand-year-old buildings are the ones that didn't fall down. The ones that collapsed within a decade are long forgotten.
A modern-day castle might survive a century whereas the castles throughout Europe remain or at least remnants of their existence survive to this day
And yet, in the village where I grew up, and near countless other villages in Britain, there was a hill with a raised mound on top, which was the only remaining evidence of the castle that stood there 900 years ago.
Re: (Score:2)
Except of course the overwhelming majority of stuff we make today would have no chance in hell of lasting 1000 years.
There are literally concrete structures created by the Romans we couldn't even begin to recreate.
This isn't just a survivor bias, it's stuff which was built incredibly well, and using techniques we can't reproduce. Even modern engineers admit that it's more than ju
Re:Modern Technology (Score:5, Insightful)
What basis do you have for the claim that we "couldn't even begin to recreate" those structures? There are certainly some ancient structures for which we haven't figured out how they were constructed with the technology available at the time, but nothing that we couldn't reproduce with today's technology.
The sticking point isn't technology—it's economics. A large portion of recent development has been around cost-effectiveness. This is why we're able to have so many more material possessions, even in the face of stagnant wages (for most classes). Of course, many (including myself) would argue that we've gone too far in this direction at the expense of durability, but that's an economic choice we've made. Look hard enough, and you can find any product that meets your durability specifications—if you're willing to pay the higher price.
That being said, I do agree with the sentiment that there is more than survivor bias at work. My house was built in 1916, and has an unusually open floor plan for its age. Lacking CAD, the builders accomplished this by massively overbuilding—the floor joists (with are already quite thick) rest on beams comprised of four 2x10's laminated together. Despite its age, this house feels more solid than just about any other wood-framed building I've been in. I have no doubt that if it were placed alongside a newly-constructed house and both left to nature, that the 99-year-old house would remain intact longer.
Re: (Score:2, Interesting)
Well, it's the way I've always heard Russian engineering described ... in the absence of finesse or the assumption of a skilled operator, you build the heck out of it, like you said. Take all of your tolerances and double them just to be sure. If you don't know your tolerances, build it as heavy as you can manage.
The techniques used to build stuff out of stone had been learned over a very long period of human history, and was used to build stuff you expected to last forever.
Roman roads, or some Roman conc
Re: (Score:3)
Because the Romans made piers and bridges which still stand in salt water, and we really can't come close to that.
Actually, that's not true. We've figured out how to make Roman Concrete but it has it's own limitations and is less safe to work with in some ways and much harder to make in vast quantities cheap. Our construction processes and material shipping methods would have to change considerably in order to use it in a widespread fashion.
Re: (Score:2)
The problem is that the economics don't really line up for the consumer. All we hear is about how spending an extra $1 on the most common point of failure in a $500 appliance would double the price. That's some really "special" math!.
People buy cheap because the expensive products turn out to be the same as the cheap product except for branding too often.
There is a such thing as overbuilding, but for the most part we are far from it today.
Re: (Score:2)
I haven't seen that. I can see how an additional 300 $1 parts might double the price though. This started as a discussion about Apple, which is a good example. The extra $.20 per screw, $5 for how the glue is applied, $25 extra for this part... turns into a few hundred extra in cost.
Re: (Score:2)
You should disassemble failed products more often and ask the questions. BTW, screws don't cost anything like $0.20 in the quantities that Apple would buy unless you use that very "special" math.
You may have lost the thread, yours is the first mention of Apple in this thread and TFA is about a UK government mainframe from the '70s.
But going with apple, considering how touchy they are about humidity, a dab of silicone putty behind the sockets would have been a good call for a cost of nearly nothing.
Re: Modern Technology (Score:2)
Re: (Score:2)
Tell you what, build a concrete structure which will be left in salt water for the next two thousand years and see if it lasts.
The Romans could do it, we still can't.
Say what you will, but there are actually ancient construction techniques we really cannot duplicate.
They may have had what we consider to be primitive tools and materials, but there are things which were built that modern engineers are trying to understand how it was done -- precisely because they know we can't duplicate the feat.
It's only in
Re: Modern Technology (Score:2)
Re: (Score:2)
Consider this, When we talk about nuclear storage facilities, we intend to build structures which will last tens of thousands of years. Good luck.
Re: (Score:2)
using techniques we can't reproduce.
Guédelon Castle [wikipedia.org]
Re: (Score:2)
Queue obligatory Monty Python reference:
When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Lad, the strongest castle in all of England.
Re:Modern Technology (Score:5, Interesting)
Without knowing *why* the castle is gone, I have no idea what your point is.
Usually, if it was a stone castle, the building materials were robbed out to make new dwellings. The reason that people could do that is because the owners abandoned them as being shit places to live.
With buildings, as with other man made items, technology moves on. Generally speaking, a house built now will be more comfortable, easier to heat and more suited to modern life styles than a house built 50 years ago. Who cares if the old ones fall down? If you are going to knock it down and replace it with something better, money spent making it last a millennium is wasted money.
Re: (Score:2)
The castles where mostly abandoned because they became obsolete. A canon will punch a hole very easily in most castle walls. Secondly the majority of the castles in the United Kingdom are close to the border between Scotland and England. Even prior to the union of the crowns in 1603 the border disputes had faded away and you no longer needed a castle.
To be honest unless it was deliberately pulled down, almost if not all the castles in the United Kingdom still survive if only as ruins. The Victorians pulled
Useful lifetime (Score:2)
You imply it is a waste to build a cheaper building, while one could argue it is a waste to over build, and commit to future expenses.
Buildings have a useful lifetime, and become prohibitively expensive... obsolete plumbing, electrical, heating cooling, insulation.
Re: (Score:2)
Buildings have a useful lifetime, and become prohibitively expensive... obsolete plumbing, electrical, heating cooling, insulation.
Those things can all be upgraded. Within the past few years, I've upgraded all of those systems in my century-old house to modern standards, spending orders of magnitude less than we would have to construct a new house of comparable finish and quality.
All mechanical systems have lifespans far shorter than the structures themselves. Even copper or plastic pipes will fail with time. Repair is almost always cheaper than tearing down and rebuilding.
Selection bias (Score:2)
I am always amazed how buildings constructed thousands, or even hundreds, of years ago are still standing although often in a state of disrepair due to neglect.
Then you are a victim of selection bias [wikipedia.org]. Those buildings that are still standing after hundreds of years are the best built ones. The ones that weren't built so well aren't around anymore. So you think that they used to build them better back in the day when in fact they mostly built them worse if anything (they didn't exactly have building codes back then) and the old crappy buildings simply aren't around to compare with anymore. Saying "they don't build 'em like they used to" is true but not in the wa
Re: (Score:2)
You only see the old buildings which were built well because the cheaply built ones have all fallen down. It doesn't mean that there weren't cheaply built buildings in the past.
Re: (Score:3)
Re: (Score:2)
You could probably flip out a modern system every year for less than the annual support and maintenance contract that the DWP is probably buying.
And you'll still have to pay the annual support and maintenance costs for the software and environment.
Hardware and associated cost isn't the issue.
If by "system" you mean hardware and software, then you're a moron. Not only could you not "flip out" a new "system" every year, you sure as fuck wouldn't want to. You wouldn't even be able to get a complete fiscal year done on one system before you toss it out and jerry rig everything onto the new system.
Re: (Score:2)
Depends on what you declare as modern. I have a Sun UltraSPARC box from the mid-90's which is still used to cross-compile things. Some things just stick around especially in government and research but also in established businesses, things are kept alive for decades because there is no funding to replace it and for most projects the people that maintain it are cheaper than establishing a new project.
This is mainly due to the inbreeding and subsequent incompetence on behalf of the people in charge of financ
Re: (Score:2)
Re:Modern Technology (Score:5, Interesting)
http://www.eevblog.com/forum/t... [eevblog.com]
nice old classic tek test gear. highly in demand by collectors and those who appreciate good old fashioned engineering and build quality. the last of the 'repairable' tek scopes, pretty much (and even this is borderline repairable, with many custom chips).
still, a few new caps, a new battery backed nvram module and you have another 20 or 30 yrs left on this scope.
search that same forum for other old test gear (power designs (brand) power supplies are also built like tanks and run forever. I have 4 of them at home in my lab and they date from the mid 50's to early 60's. still hold their precision and would cost $5k to $10k today if you could even buy them.
I have audio gear that I personally built in the 70's and 80's that still runs fine (hafler amps, etc).
today, its hard to find things built to last, but it USED to be the norm "before your mother was born", so to speak.
Re: (Score:2)
Re:Modern Technology (Score:5, Insightful)
Because, as a student, if you hit it and it breaks you did something dumb and reduce the number of units for the class to use. However, as an instructor, if he hits it and it breaks, it was due for replacement.
Re: (Score:2)
Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Knight turned the machine off and on.
The machine worked.
http://en.wikipedia.org/wiki/Hacker_koan
Re: (Score:2)
Well, no. While it's true that the race to the bottom has increased over the last few decades - things pretty much have always been "built to sell", and if they lasted that was a bonus rather than a design feature.
New Platform (Score:5, Funny)
Port it to minecraft. There seems to be some good 1970's CS work happening there.
Re: (Score:3)
Re: (Score:2)
old != bad (Score:5, Informative)
My money is on this VME system being around for another 20 years while the mess of Java and Oracle(you know they're going to use Oracle). It'll be overpriced, late and won't actually work.
Just because something is old, doesn't mean it needs replaced. In short, why not just upgrade the mainframe?
Re:old != bad (Score:5, Interesting)
Nono, like other big IT projects in the UK, it will be using "the very latest in Agile know-how", and cost 3 times as much as any clusterfuck that involves Oracle, take 50% longer, and spread 300% more blame on "old fossiles"....
Disclaimer: Had to interface with a EU project under UK IT auspices last year.... Painful....
Re:old != bad (Score:4, Insightful)
Just because something is old, doesn't mean it needs replaced. In short, why not just upgrade the mainframe?
I have no idea how common VME developers are, but when dealing with legacy systems you do have to worry about being able to find qualified people to work on your software. Not only are the skills rare, but most people are going to be wary about pigeon-holing their career by focusing on such a obscure system. You will either have to rely on sub-par employees or pay well over market rates.
Hiring expensive employees / consultants may still be desirable over a risky migration, but the expense (either in salary or in low quality employees) shouldn't be ignored.
Re: (Score:3)
I have no idea how common VME developers are, but when dealing with legacy systems you do have to worry about being able to find qualified people to work on your software. Not only are the skills rare, but most people are going to be wary about pigeon-holing their career by focusing on such a obscure system. You will either have to rely on sub-par employees or pay well over market rates.
These days, I'd take more job security over "over market rate" salary and fancy perks. As long as I can pay my bills, the work is fairly interesting, my teammates and managers actually appreciate me and value my skill set - and I'm not micro-managed to death, I'd be happy to pick up some VME skills.
I don't consider myself a "low quality" employee, I just don't have fancy tastes or a tech-toy habit to feed (nor do I have kids). Now 51, I have always lived responsibly, am debt-free (with enough savings/in
Re: (Score:3)
Changed? Sure.
Improved? Well, the jury is out.
Re: (Score:2)
Changed? Sure.
Improved? Well, the jury is out.
If I was on the jury, I'd vote that it's NOT better in the last 40 years.
But.... I'd also say it's not any worse either. Software development as an engineering process hasn't gotten better or worse since it was invented.
Re: (Score:2)
The software is the easy part. Figuring out how to replace 40+ years of business knowledge stored in the older software is the hard part. ANd why most upgrades fail in terms of massive cost over runs, damage to business processes, and slipped schedules.
Re: (Score:2)
Code doesn't breakdown, if it works now it will work 100 years from now if the hardware is still running.
You've either never supported someone else's Java application or you're a straight troll.
It's rare for a Java application to work 100 days after it was last working with all of the timebombs they build in now.
Re: (Score:2)
The code that truncated years to two digits (Y2K bug) or relied on the epoch clock (2038 bug) were not designed to work past year 1999 or 2038, try were built with limitations that were accepted by the developer, testers, and users - even if they didn't understand the trade-off they made or the self-imposed self-destruct mechanism they hard-coded into their program. In effect, they were designed to fail, so I guess one could argue they 'work as defined', they were just poorly defined.
Re: (Score:2)
They were NOT designed to fail.
Nobody conceived they'd still be running that long, but if they'd been designed to fail they would have done so by now. Having your usable life be decades longer than expected is not evidence of bad quality.
If code written in the mid 70's is still running 40 years later, that's kind of the opposite of doomed to fail. Code written in 1974 was old enough to vote or buy alcohol by the time Y2K came along.
I predict very little code written in 2015 will be running in 2055.
Does it still work? (Score:3, Interesting)
Re: (Score:3)
Government contracting money.
Re: (Score:3)
Depends what the requirements are.
Usually, this sort of thing happens because requirements are changing faster than the old system can be maintained to keep up.
I wouldn't be surprised if this is to help automate the swingeing series of "sanctions" that are carried out to remove the benefits from job seekers in this country.
Things like suspending their payments for...
* Being late for an appointment at the job centre (by approx 2 minutes).... because they were attending a job interview
* Not attending a job in
Re: (Score:2)
What are the tangible benefite of a new system?
Keep in mind that all of these are only possibilities:
1. Reduced operating expenses. Modern computers are much more power efficient than old ones
2. Faster response time. If you keep the visual wizz-bangs to a minimum a modern system should be able to serve up a search faster
3. Cheaper hardware replacement, edging towards 'actually able to replace it'. Remember NASA hitting garage sales up for old parts? The old hardware tended to be very robust, but it still fails on occasion, and it's not made anymo
Re: (Score:2)
1) Bogus, increases in hardware capabilities has always been gobbled up by bloated software.
2) Yeah..... right. The first impulse will be to slap on a shiney new GUI. And the monkeys hired to code it will probably use bubble sorts or worse code.
3) Emulators
4) How about 'growing your own'? Remember, the hard part is not learning to program, that can be done in a couple of years. The hard part is understanding the business rules.
5) If you use an emulator you have plenty of hardware space, though you might hav
Re: (Score:2)
1. False. Frequently true, but not 'always'. I've seen rooms freed up in exchange for two cube shaped servers under a desk, with the operators praising how fast things now were...
2. See initial disclaimer (only possibilities) and I put the visual wiz-bang specification in there for a reason.
3. You need somebody to program the emulator. They aren't always available.
4. I actually mentioned 'grow your own' - it can get really expensive, because new people don't want to be locked into your legacy system
Re: (Score:2)
Ability to find parts on for the aging system is probably becoming more and more difficult. Regardless of the software platform, the OS is aged enough where certain parts are bound to be harder and harder to obtain should they need a replacement.
There is also something to be said about reviewing all the business rules and updating them to meet their current needs. That usually happens during a revamp of the system.
It is called good coding. (Score:5, Insightful)
Many people are shocked that computers/systems for 20 years still run, but is says a few things:
1. That people are used to crap code that can't keep running.
2. That people are used to crap products that can't last for more than a couple of years.
If it ain't broke, why fix it? They sent man to the moon on less CPU horsepower than my Nexus 6. Voyager has been running for more than 35 years in the harshness of space.
Re: (Score:2)
News Flash.
The US's ICBMs are from the 1960s and the US still uses tankers and strategic bombers from the 1950s.
Good stuff lasts.
Re: (Score:2)
The requirements in those fields don't change.
"Drop the bomb on the target" is a problem defined by the laws of physics. I've seen artillery pieces with old brass analog computers that still work perfectly.
"Make a system that automates the processing of the asinine new rules for Job Seekers Allowance" is a moving target.
Re: (Score:2)
But the Job of the OS has not. VMS is actually a great OS for this kind of system. Frankly it is a real shame that is in the Hands of HP today.
Ship of Theseus (Score:2)
The US's ICBMs are from the 1960s and the US still uses tankers and strategic bombers from the 1950s.
B52s have been rebuild and upgraded and refurbished so many times they may as well be the Ship of Theseus [wikipedia.org]. Furthermore the munitions they carry aren't really the same either these days in most cases.
Re: (Score:2)
The US's ICBMs are from the 1960s and the US still uses tankers and strategic bombers from the 1950s.
1. They still have a lot of upgrades since then
2. We're running up to some timelines where we're going to have to spend a lot of money to replace them, especially the ICBMs, because they just can't be extended anymore and the equipment to manufacture replacements no longer exists. More importantly, the skills to make replacements using the old techniques no longer exists in many cases.
Re: (Score:2)
Re: (Score:2)
Which is why I said 'especially the ICBMs'. We're actually trying to buy new tankers right now.
Re: (Score:2)
If it ain't broke, why fix it?
Code churn. Can't make contracting money by not rewriting things all the time.
Re: (Score:2)
Not really. We're not surprised that systems from 40 years ago are still able to do the things that they were designed to do, we're surprised that the requirements haven't morphed beyond all recognition in this time. If you spend three years developing a software system, and at the end of those three years your requirements look even remotely similar to the ones you started with, then these days you consider yourself very lucky. The idea that you could deploy a system and 40 years later your customer wou
Re:It is called good coding. (Score:5, Insightful)
They have. But they didn't do it overnight, they did it small bits at a time and those 40-year-old systems were patched or updated and debugged with each change. The result is a twisted nightmare of code that works but nobody really understands why and how anymore. And the documentation on the requirements changes is woefully incomplete because much of it's been lost over the years (or was never created because it was an emergency change at the last minute and everybody knew what the change was supposed to be, and afterwards there were too many new projects to allow going back and documenting things properly) or inaccurate because of changes during implementation that weren't reflected in updated documentation. As long as you just have to make minor changes to the system, you can keep maintaining the old code without too much trouble. Your programmers hate it, but they can make things work. Recreating the functionality, OTOH, is an almost impossible task due to the nigh-impossibility of writing a complete set of requirements and specifications. Usually the final fatal blow is that management doesn't grasp just how big the problem really is, they mistakenly believe all this stuff is documented clearly somewhere and it's just a matter of implementing it.
Re: (Score:2)
I wouldn't be too sure of that. While the Apollo guidance computer didn't have much horsepower, it didn't *need* much horsepower... it was mostly a crude control system that performed only very basic calculations. All of the heavy number crunching was done by multiple mainframes on the ground and the results uploaded to the vehicle. Or, to put it another way... the CSM and LM computers were basically peripherals.
Re: (Score:3)
In the Apollo timeframe, a "supercomputer" would be a CDC 6600 (1964).
3 MFLOPS and up to 10 million instructions per second, 60 bit word size, 262144 words of main memory (~3 million 6 bit characters) -- yes, your smartphone is more powerful. This was STILL the most powerful mainframe in 1969.
It is broken (probably) (Score:5, Insightful)
Many people are shocked that computers/systems for 20 years still run,
Only people who don't know much. It's not shocking that such a thing would happen or that hardware can be made that robust. What IS shocking is that people put systems in place without any thought whatsoever to what people might want to do 20 years later. Seriously do you REALLY think it will be efficient or practical without problems for you to use the PC you are reading this on today in 20 years? Why would it be any different for a business or government?
If it ain't broke, why fix it?
Because it probably IS broken in a multitude of ways. Just because it can get a specific job done doesn't mean it does so efficiently or without problems. I've driven a lot of beater automobiles over the years and while they usually got me from point A to point B they were unquestionably broken if a number of ways. I have PCs that are 10-15 years old here in my company doing specific jobs and they definitely have problems. Yes we still get some productive work out of them but that doesn't mean I shouldn't think about replacing them when I can.
They sent man to the moon on less CPU horsepower than my Nexus 6.
Because that is all they had at the time. Nobody would even dream of doing that way today because we have better options now. Why limit yourself to yesterday's technology if you have a choice?
Voyager has been running for more than 35 years in the harshness of space.
Which is relevant how? You're comparing a spacecraft that human eyes will never see again with a earthbound computer system that we can modify or replace any time we want.
It's paid for. (Score:2)
Besides, banks are even worse. They're still running virtual COBOL card systems in their basements.
Re: (Score:2)
Re: (Score:3)
Listen up, Junior ...
In some ways, Token Ring was very much superior to Ethernet. A hospital I worked for in the late 90's had a huge (1000 nodes) 4Mbps TR, all as one big subnet, built long before switches came along. If you tried to do that with Ethernet, it would have crashed and burned in a week. This was, on the whole, pretty reliable (if slow). The downside was that if one card in the ring failed, the whole thing would generally die. So it was great until the 10 year old TR cards started failing
Re: (Score:2)
Re: (Score:2)
The downside was that if one card in the ring failed, the whole thing would generally die.
As I recall, that "downside" pretty much single-handedly killed the technology. It's a big deal.
Paging John Titor (Score:2, Funny)
John Titor... Please report to... Oh, nevermind. Some bloke in a blue callbox has already claimed it.
2038 (Score:2)
Re: (Score:2)
They deal in pensions.
Likely their applications were dealing with dates past 2032 decades ago.
The only problem is whether the hardware ticks over but given other comments, it looks like it's a virtualised system nowadays on more modern mainframe hardware.
Chances are they're the one place that won't care about 2032.
Orange Leos? (Score:5, Interesting)
I wonder if they are running "orange Leos"? Here's a post from alt.folklore.computers in 1998. Terribly impressive. I'm not sure his age estimate is necessarily accurate, though: the final incarnation of the Leo ceased to be manufactured in the latter half of the 60s, so it may be a bit younger.
From: Deryk Barker (dbarker@camosun.bc.nospam.ca)
Subject: Re: Multics
Newsgroups: alt.folklore.computers, alt.os.multics
Date: 1998/11/09
[...]
When my wife was working for Honeywell, in the 1980s, one of the
customers she had dealings with was British Telecom.
BT, at one location, had what they called the "orange Leos".
Now, for those who don't know this, the LEO was the world's first-ever
commercially-oriented machine (1951). Even more amazingly, the Lyons
Electronic Office was designed and built by the J Lyons company,
best-known as manufacturers of cakes and for their nationwide chain of
corner tea shops.
Anyway, an "orange Leo" was an ICL 2900 mainframe (they came in orange
cabinets), emulating an ICL 1900 mainframe, emulating a GEC System 4
mainframe emulating a LEO.
30+ year old executable code over 3 architecture changes....
Re: (Score:2)
I miss the days when we had distinctive designs in the data center. Big blue mainframes, orange and blue DEC 20s and 10s.. Now it's all racks and the only blinking lights are on the switches :-(
Extreme example here, but... (Score:5, Interesting)
Not all legacy stuff is bad. Not all legacy stuff should be kept around to the point where you can't find people to run it, however,
I've had experience working in die-hard IBM mainframe shops as well as places that used the HP MPE operating system on the HP 3000 minicomputer system. In the 3000 case, the customer was relying on a service provider that was providing an application that was way way way out of date but still worked. All the IBM places I've ever worked have been slowly "modernizing" their application stack, but in most cases, the core transaction processing has remained on the mainframe because that was the best solution. It's extremely rare these days to see an end user facing green screen application, but they do exist as well. (Yes, I work in "boring" old school industry sectors, very few web-framework-du-jour hipsters here, but we're also not old farts.)
The problem I've seen is that vendors love the fact that customers are locked in and will do nothing to encourage them to get off. Most ancient mainframe code can run virtually unmodified on newer hardware, and that backwards compatibility is a big selling point. It allows IBM to go in, swap out your entire hardware platform at $x million, and keep billing you by the MIPS without changing any code.
But...the reverse problem is that "mainframe migration" projects often end up becoming case studies of how Big Consulting Company X was paid hundreds of millions to not deliver a working system. I believe I read about DWP's "Universal Credit" project that has Accenture, IBM or Oracle written all over it. These kinds of projects usually try to port all the business logic and transaction processing to some horrible-to-maintain J2EE monstrosity backed by an Oracle database. They usually fail because (a) no one correctly estimates the work required to pull all that business logic out of 30+ years of cruft, and (b) the consulting companies replace their star team (that travels with the sales force) with new grads in India (who do the actual work.) I've seen this cycle over and over again, and am still amazed that CIOs aren't wary of consultants.
Why migrate? (Score:2)
Hello, Big Bank Here.... (Score:2)
And we are running an IBM Mainframe. Yes, it's been upgraded to zOS, but it's fully OS360 compatible and I regularly review Cobol code with comments going back to 1980. There's been a push from above to use the Control_M "GUI" interface, but a lot of the folks here are resistant, since we have faster and better control via the terminal (sorta like GUI versus Command Line).
And yes, my Windows workstation is simply a glorified terminal as I spend all day logged in to the mainframe itself (green screen apps).
Dust off the CV (Score:2)
VME is unfortunately on my CV. What I'm amazed is that they can still get parts for the damn thing.
Is it broken? Is it unsupported/sunsetting? (Score:2)
If it's not broken, it gets the job done, it's vendor-supported, and you don't expect that support to end in the foreseeable future, then I don't see the problem.
Age alone is not any reason to declare technology obsolete.
Here's a common example: Stores still sell 4-function calculators for $5 or less. As far as the user is concerned, they are less-expensive versions of the same calculators you could buy from the mid-1980s on, and thinner-and-cheaper-with-LCD-and-button-battery versions of the kind you cou
The California DMV has them beat. (Score:3)
The California DMV has them beat, they are still using code installed on UNISYS mainframes in 1970 to run the DMV core applications.
It is as old as I am...
Re: (Score:2)
Re: (Score:3)
It is a bus and connector specification.
"VME" can refer either to the VME operating system [wikipedia.org] or the VMEbus [wikipedia.org].