Vendor and code lock-in, mainly.
Why are we still using Mainframes?
11–19 of 19 posts
Re: Why are we still using Mainframes?
#12>> Do we have any alternatives? How easy is it to migrate? Oh god, no, don't even think about it. It's hard enough migrating away from a code base in Java, written 10 years ago and that runs on pretty much anything. Imagine how hard it is to migrate from a code base written in languages known best by engineers in retirement, that only runs on extremely expensive supercomputers made by almost a single company (IBM). B…
It's been done. Design and implement a replacement system, run it in parallel for a meaningful timeframe, then switch over. You need a parallel implementation simply as a "hot backup" in case your primary system fails for whatever reason anyway, and it's easier to implement real-time redundancy in current systems anyway. (This was the niche that Tandem Computers served.) I think most mainframes in the USA are used to…
Without disclosure of past employers: huge international banks still use mainframes. Regular employees access them via custom software to flip data left and right as necessary. In my experience, penny-grabbing and a lack of will to push to new technologies is what keeps these system alive. It is not in the interest of anyone to make change happen. Management is there for their annual bonus, not their 10 year goal to spend money substituting systems that are working 'fine' in the here and now. That is not how you make a career in these institutions. See Dilbert for more information.
Re: Why are we still using Mainframes?
#13Why? Because they work.
Re: Why are we still using Mainframes?
#14Earlier quoted context omitted.
Similarly this is why, in some places, people report having "that old XP machine running in the closet" because is really important to them and they have no path forward (it doesn't support > XP, it's actually too vital - though that seems like an odd reason not to update, etc.). You could replace these things with something newer but the concerns by various parties can outweigh the willingness to fight and you proba…
The XP factor is another good reason why people stay on mainframes. They tend to be supported forever, or as near as dammit. You don't get that (quite reasonably) with consumer grade software and hardware.
Also, IBM Z series provide full backward compatibility [1], so you can have new hardware and still run your COBOL program from 1976 with no issues.
Re: Why are we still using Mainframes?
#15Earlier quoted context omitted.
It's been done. Design and implement a replacement system, run it in parallel for a meaningful timeframe, then switch over. You need a parallel implementation simply as a "hot backup" in case your primary system fails for whatever reason anyway, and it's easier to implement real-time redundancy in current systems anyway. (This was the niche that Tandem Computers served.) I think most mainframes in the USA are used to…
Without disclosure of past employers: huge international banks still use mainframes. Regular employees access them via custom software to flip data left and right as necessary. In my experience, penny-grabbing and a lack of will to push to new technologies is what keeps these system alive. It is not in the interest of anyone to make change happen. Management is there for their annual bonus, not their 10 year goal to…
I'm not a massive fan, but it's a risk-reward calculation. What could new hardware do or offer that is compelling enough to spend millions of [currency] and run the risk of putting in place a new platform?
Re: Why are we still using Mainframes?
#16Earlier quoted context omitted.
It's been done. Design and implement a replacement system, run it in parallel for a meaningful timeframe, then switch over. You need a parallel implementation simply as a "hot backup" in case your primary system fails for whatever reason anyway, and it's easier to implement real-time redundancy in current systems anyway. (This was the niche that Tandem Computers served.) I think most mainframes in the USA are used to…
Without disclosure of past employers: huge international banks still use mainframes. Regular employees access them via custom software to flip data left and right as necessary. In my experience, penny-grabbing and a lack of will to push to new technologies is what keeps these system alive. It is not in the interest of anyone to make change happen. Management is there for their annual bonus, not their 10 year goal to…
I really can't imagine that cost is a factor... it has to cost more to support a mainframe environment (especially assuming the need for a raised-floor, Halon-protected, chilled computer room and oversized, power-hungry peripherals) in anything but the shortest term.
Re: Why are we still using Mainframes?
#17Because changing code and process is hard.
I worked at a place operating a Unisys mainframe running code written mostly from 1972 through 1985. That "mainframe" is probably a 4U Xeon with an emulator running on it. There have been active projects (and easily a billion spent) to replace that mainframe since at least 1996.
Remember that mainframe systems mostly automated totally manual tasks, so businesses were literally built around them. The use cases left are mostly core applications like general ledgers, rules engines for big complicated processes, etc. They work pretty well, and most of the modernization budgets get spent replacing supplemental systems running Solaris, Windows, etc that are aging less gracefully than the mainframe.
Re: Why are we still using Mainframes?
#18Earlier quoted context omitted.
It's been done. Design and implement a replacement system, run it in parallel for a meaningful timeframe, then switch over. You need a parallel implementation simply as a "hot backup" in case your primary system fails for whatever reason anyway, and it's easier to implement real-time redundancy in current systems anyway. (This was the niche that Tandem Computers served.) I think most mainframes in the USA are used to…
Without disclosure of past employers: huge international banks still use mainframes. Regular employees access them via custom software to flip data left and right as necessary. In my experience, penny-grabbing and a lack of will to push to new technologies is what keeps these system alive. It is not in the interest of anyone to make change happen. Management is there for their annual bonus, not their 10 year goal to…
>> See Dilbert for more information.
I guess we 've worked in the same place then :)
Re: Why are we still using Mainframes?
#19>> Do we have any alternatives? How easy is it to migrate? Oh god, no, don't even think about it. It's hard enough migrating away from a code base in Java, written 10 years ago and that runs on pretty much anything. Imagine how hard it is to migrate from a code base written in languages known best by engineers in retirement, that only runs on extremely expensive supercomputers made by almost a single company (IBM). B…
It's been done. Design and implement a replacement system, run it in parallel for a meaningful timeframe, then switch over. You need a parallel implementation simply as a "hot backup" in case your primary system fails for whatever reason anyway, and it's easier to implement real-time redundancy in current systems anyway. (This was the niche that Tandem Computers served.) I think most mainframes in the USA are used to…
>> You need a parallel implementation simply as a "hot backup" in case your primary system fails for whatever reason anyway
Mainframes have backup built-in already, and then they're also ran in twos with one as further backup. The amount of redundancy built in those systems is just insane and quite unmatched by anything in the "distributed" world.
So for example where I work(ed) the mainframe network is touted as having 99,999% uptime. In my time there, there was an "outage" that affected the whole business quite severely... and it was on a distributed (not a mainframe) server. I don't think anyone remembers the mainframes ever having failed for good.
They're just beasts. There's solid reasons to use them the way they're used. The fact that they're a bit archaic... well, to be fair so is Linux. So what? If it works, it works.