https://learn.microsoft.com/en-us/dotnet/csharp/programming-...
https://hackage.haskell.org/package/postgresql-typed-0.6.2.4...
It is never technical or pratical reasons, always economic reasons. To use contemporary vocabulary, you "just" need to replicate a "multi tenant HA cloud environment" to migrate from a mainframe at great cost.
> And now we are in a situation where their long held beliefs have become true because nobody is around that understands how or why the software works the way it does.
Statistically unlikely, most of the business software that goes onto said mainframe is in fact very simple and straightforward and can be easly ported out, however, the real deal is all the integration and high availability logic built-in into "the mainframe platform". You're not porting that out without replicating said "multi tenant HA cloud environment" at great cost.
Whereas on mainframe the service processors can deal with it transparently to the CPU using specialized hardware.
And let's say it's financial transactions - fixed-point decimal arithmetic. On mainframe, that can be hardware accelerated too.
That said, it is not at all clear to me that the TCO of a maxed-out IBM DS8900F is less than $30 million/year.
Yeah no. I worked on mainframe code for 15 years of the last 20 and can tell you that you’re wrong. Even reasonably simple business lines have cobbled together insane cobol, batch and cics screens that would make spaghetti blush.
When you open up a 100,000 line batch program that’s just 1 of 30 cobol programs in that run which is a mess of gotos, global mutable state and basically every single other generally frowned upon software practice we know about, you start to understand the issues.
Moving off of mainframe is practically impossible because of it. That other person being voted down is actually correct, nobody in the organization actually knows how any of it works.
When organizations try to transition away, what ends up happening is they get these insane promises of “5 years” from vendors (like IBM. Ask me how I know!), but then it takes 10 years to transition single systems.
Nothing is documented. So you have business people who have no clue how anything works providing high level work flows. But then there’s always 50 random edge cases or interactions they never considered cause the 40 year old code just does it.
IT contains most of the business knowledge, but the mainframe grey beards are… stubborn. The business hangs on to these people because they’re seen as insanely valuable, not realizing that the grey beards have actually been actively suppressing knowledge to only their hidden documents, and they’ve got 8 years till retirement and are going to make sure that their job exists at least until then by actively sabotaging efforts to change. But also, for some reason, the business manager love the saboteurs. It’s insane to watch.
how do you know?
Because they keep the shit running. If you're a bank and responsible for trillions of dollars in assets and billions of dollars in daily transactions, the absolutely last thing you can afford is downtime or, even worse, data loss. You'll not just have to handle a ton of angry customers, but in the worst case attract regulatory attraction or getting dragged in front of Congress and the courts.
Here in Germany, Deutsche Bank is integrating 12 million accounts from Postbank to their own IT systems, and it has been an utter utter shitshow [1], attracting a lot of bad press and the banking regulator BaFin is also investigating [2].
[1] https://www.merkur.de/leben/geduldsprobe-fuer-postbank-kunde...
[2] https://www.sueddeutsche.de/wirtschaft/deutsche-bank-postban...
> It is never technical or pratical reasons, always economic reasons. To use contemporary vocabulary, you "just" need to replicate a "multi tenant HA cloud environment" to migrate from a mainframe at great cost.
When your business processes are so ossified by a mainframe that you have, say, groups preparing Excel spreadsheets -- with data formatted from one mainframe screen in 3 columns -- for use by another group to input back into the mainframe -- with the data reformatted in 4 columns -- you know you're never escaping the gravity well of the black hole at the center of IT that is "The Mainframe." This is just how it's going to be until the company is so technically irrelevant that the remains are picked up in a fire sale by some PE to sell off to some other, tangentially-related company, solely for the IP assets.
I worked at one company that is trying to replace their mainframe. The project is now in its second decade. The company has the burden of supporting the mainframe application and now the 'modern' application. The project is still a few years away from being able to completely shut off the mainframe.
Oh and the modern application is also showing its age as the business has changed and the modern system built assumption in from the mainframe system and in many ways is just as inflexible to change as the mainframe app was.
This is why companies aren't scrambling to replace their mainframe systems. They are happy to continue paying for the high cost of compute on these systems because its still cheaper and less risky than replacing the system.
And then in 5 years someone can rewrite it all again because something else will be cooler and my code will be technical debt.
I don’t think you’re making argument think you’re making.
I’m not saying that you should stick to mainframe. But rewriting it because you need to support strong password is not a reason to do it.
So what will happen when in 10 years the last people you have that know how it works are retired?
Not to mention tech debt.
https://www.youtube.com/watch?v=hxxyORcU3Hs https://blog.share.org/Article/mainframe-visibility-ibm-cham...
Want to learn Windows, Linux, cloud whatever? Just build a cheap home lab and play to your heart's content. Because really, training is not how you get good. Nor is certification. It's the hands on experience that comes from running into the crap the vendor doesn't want to tell you. All the little annoying flaws they keep out of the documentation under pressure from marketing.
Good luck doing that with a system Z. Try to find one on eBay for peanuts the way you can get a nice ESXi server.
When folks have replaced significant enough chunks with other apps, or otherwise made the prospect less daunting, then it may happen. It just comes down to cost and risk management.
I was part of a 4 person team that knocked this out in under a year. 1,000's of mainframe programs running w/o change (at the time) on Unix. This was in the 90s.
I worked with both DB2 & UDB during my internship 2 decades ago, and while largely compatible with core SQL functionality, that changed quickly after you got off the "normal" path. UDB was released at a much faster cadence, and if you developed to the latest features of UDB, you'd often find yourself unable to deploy against DB2.
A few of my last projects as an intern: 1) storing BLOB objects in DB2 from a .Net app and 2) porting an "interactive" batch-processed COBOL app to ASP.Net form 3) getting DB2 Connect clustering on windows working (I never did get this working despite spending an entire summer on the phone with IBM support).
I've some fond memories of working with the mainframe. Like the time I managed to crash the entire development LPAR with a specific SQL query that broke the DB2 query optimizer... The phone call from the NOC was immediate and went something along the lines of "I don't know what you did, but don't do it again, you just took down all of development". Development was something like +10k users...
We actually targeted Oracle on Unix. Fortunately, the app developers never got too deep into DB2-isms, so it worked out fine.
I'm not really a fan of mainframes, only pointing out that the companies still on them are generally on them as a direct replacement to general purpose servers isn't purpose fit, and conversion is excessively costly, even compared to IBM mainframe contracts.
The hardware might be whiz-bang but the legacy applications are slow, outdated, and extremely hampered in functionality.
In my state, the birth records system is electronic, and so is our RMV. But in order to get a RealID, I had to get a paper copy printed out to bring to the RMV because they can not, or will not, integrate the two systems. Meanwhile other countries have things like electronic ID cards with personal certs so you can electronically sign documents and identify yourself.
The whole thing is a giant puff piece for IBM, reading like a sales presentation transcript.
Most of these kinds of systems have decades of codified knowledge that applies the legal requirements of many disparate jurisdictions in these systems. Laws vary from city to city, county to county and state to state, and that's only for the US. Some of these systems implement code that applies legal requirements for dozens of nations.
In general, you're going to have to spend at least a year just to document the existing system. Another six months to a year generating test cases and scripts for validation. And that's before even starting to build the new system. And that is ALL optimistic, assuming everything goes right.
I had to once write a relatively simple application for "vacation bidding" where in employees will get a position to request certain weeks off during the year. This was a legal requirement and happened to involve the company, two other companies that had been merged in and three unions. Each with different rules regarding how seniority is calculated. The contractual specifics were over two thousand pages long. That's just one very small piece of software in one of these very large companies. It took the better part of a year to implement. Now imagine taking that a couple decades later after it's evolved and migrating to an entirely new platform and paradigm. Now imagine the cost to do that.
E.g. how many variants of IRC have we had now? Usenet? VMs?
Progress is supposed to work by standing on the shoulder of giants. But that only works if engineers are aware of what came before, how it worked, what was good and bad about it.
In the software world the same things are continuously being reinvented but the lessons of the past are not integrated because the inventors have no knowledge of the past 10 times the same thing was done. So every lesson has to be learned anew in production. That's not progress.
A very very good paper, and one that was clearly a passion project for the prof.
Additionaly the campus library was a treasure trove from computing books all the way back in time, and many of us dived into them.
But it was an elective, and as I found once I got into the real world, one that most people either opted out of or didn't have the option to take. I spend way too much time providing Cliff's Notes to a class I took almost thirty years ago.
All the truly important CPU design features were first invented using discrete logic for mainframes and minicomputers. Then, 20 years later when it became possible to fit them onto a single chip, they were all out of patent, which is precisely what made the early microcomputer industry so competitive. When none of the important stuff could be patented anymore, you could only compete on merit, not by getting a government enforce a monopoly on some critical piece of your design.
The Javastation network computer for example, it was a bit like a Chromebook (though incredibly slow -lol)
Why pay for disk and compute access when you can have a workstation! Why have limited access to the system when you can have your own! Was the vibe.
It is amusing/sad that in the AWS world we're right back to basically mainframes. Centrally hosted massive compute that you don't really have full control or access and have to pay for use time.
I wonder when the next swing back to personal computing arrives?
The pendulum swings, and never seems to stop.
https://en.wikipedia.org/wiki/Service_Bureau_Corporation
https://en.wikipedia.org/wiki/Second_Computer_Inquiry
It takes time and wastes effort, but technology eventually bests politicians.
Vertical integration of the business into one magic box is a perpetual dream of mine. Bonus points if I can yell at exactly one vendor if anything goes wrong.
Last time I tried I had issues with the VPN and couldn't connect to it. I'll try again later. Another good thing about IBM cloud is that they embrace Terraform and you can download templates for just about everything they offer.
The Main Frame of yore was ... one of the 19 inch racks the computer was made out of (the main one, typically with the ALU and registers in it). And those racks were used because that was how phone systems were built (phone systems had a lot more repeated / regular structure than something like a computer, though of course everything has converged). The "frame" nomenclature came from the phone system too.
So "normal servers today" got the rack from the mainframe, the mainframe didn't adopt it because of how datacenters were built. All the familiar stuff (raised floors, chillers, backup power, fire suppression, controlled access doors and so on) come from the mainframe world.
Hot plug CPUs, memory modules, and DASDs. All survive the failure scenario gracefully.
Good luck trying to do that on a rack of x86 servers.
I think as in most engineering things. They do a different trade-off and cater to a different niche while x86 servers are the mass market consumables that most workloads -should- be using. The mainframe CPUs go for the widest IO capabilities, insane cache sizes and hardware offload because that’s what their target audience(banks, insurance companies, airline ticket systems) need.
Their parallel sysplex clustering solution is an engineering marvel but also tightly coupled to their hardware.
In some ways, the IBM mainframe is the Apple of niche critical enterprise computing. They are also the ancestor of cloud computing in paving the way for “pay per use” cost models and multi tenancy.
I liked to use Google's App Engine classic environment (the Python 2.7 one) as a good example. It really hammered down some good practices (such as keeping the filesystem read-only) and gracefully handling degraded modes such as a datastore that becomes read-only for no reason or the cache that's supposed to be there that just isn't. It was a great teaching tool.
Running a Postgres cluster or a Kafka cluster on a bunch of x86 machines sure gives you scale, but definitely brings the pain of handling availability scenarios for write consistency. Distributed locks and distributed data stores that use Raft/Paxos serve as a good reminder of how hard it is to achieve them. If IBM could do it at hardware level, some Enterprise customers are willing to loosen their rich wallets for that comfort.
The processor checkpoints state, and if an error is detected it can be rolled back and the checkpoint moved to another physical processor and re-started transparently to software. Stores are tracked all the way down to "RAID memory" (actually called RAIM), whereas in other CPUs they get punted off at the L1 cache. Practically every component and connection is redundant. There are stories of mainframe drawers being hauled to particle accelerators and the beam switched on while they're running. Quite amazing machines.
Not to say that has more value than the software (I don't know one way or the other), but the hardware is no gimmick.
Going back to the hardware that everyone likes to focus on, it's less radically different from normal servers today than it was historically. The mainframe today is a 19 inch rack like any other. By that i mean it is not only a 19 inch rack like your x64/ARM servers are but also the same power density (32 or 64 amp racks), cooling requirements etc.
The most interesting bit is the software, not the hardware. There are cool hardware aspects too - but focus on them and you miss the real reason these things are popular in certain environments.