
Why are we still using Mainframes? - parialegend
Why are we still using Mainframes? Do we have any alternatives? How easy is it to migrate?
======
lucozade
In my experience, mainframes tend to be used where functional requirements are
very slow moving and reliability trumps flexibility.

I don't know of any case where a mainframe couldn't, in principle, be replaced
by a server farm. However, maintaining a sufficiently reliable and secure
server farm is a specialist job too so the benefits aren't always clear cut.

Ease of migration is really down to what the mainframe is doing and for how
long. In practice, they tend to be in place for a number of years in hub-type
roles e.g. general ledgers, payment systems. That sort of thing. The effect is
that extricating them is extremely complex and expensive.

However, these issues aren't really limited to mainframes. We have the same
problems with trying to extricate Sparc Solaris applications. We generally
want to replace them with Lintel as we use them in most applications. But
doing so is horribly complicated as they're embedded in byzantine flows that
few understand and the systems often assume a level of hardware reliability
that commodity boxes don't have.

~~~
cakes
Similarly this is why, in some places, people report having "that old XP
machine running <software> in the closet" because <software> 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 probably don't
want to be on the receiving end of "I told you so".

~~~
lucozade
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.

~~~
gadders
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.

[https://en.wikipedia.org/wiki/IBM_System_z#Architecture](https://en.wikipedia.org/wiki/IBM_System_z#Architecture)

------
YeGoblynQueenne
>> 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).

But the worse thing is that you can't just pull the guts out of the software
that runs all the transactions of huge financial organisations. You can't just
throw a switch and stop all financial activity in a big bank, while you swap a
new system in place, because every second of downtime costs millions.
Millions! Who is going to take the responsibility for that?

So change never happens because nobody dares make it. One day mainframes will
outlive the last people who can program them competently and then we'll all be
in trouble.

~~~
DrScump
<You can't just throw a switch and stop all financial activity in a big bank,
while you swap a new system in place, because every second of downtime costs
millions.>

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 run old legacy systems that
will be needed not much longer (or that's the _plan_ , anyway), like shop-
order control for old weapons systems -- tasks for which no replacement system
would be necessary because the need ends with the project.

~~~
Zelmor
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.

~~~
DrScump
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.

------
Spooky23
Because 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.

------
executesorder66
I think it is because it is the easiest/cheapest way to reliably handle a
fuckton of transactions. So it's great for a bank. I can't think of any other
use cases though.

------
DrScump
Legacy code bases.

I wonder how much of my 1986 code is still in use.

~~~
pestaa
Out of curiosity: what did you write in the 80s?

~~~
DrScump
That was in the defense industry; if I told you, I'd have to kill you... and
everyone else reading. That's too much work.

------
Zelmor
Vendor and code lock-in, mainly.

------
gadders
Why? Because they work.

