Right, it can and does happen. The following is an opinion, and one I'm surprised to have arrived at, but here I am. Warning: long ramble ahead.
The companies who embark on a mainframe exit and succeed successfully (as opposed to just managing to transition off, but without winding up being particularly happy about it) tend to be those whose core applications weren't custom-built. This means that the older and/or more of a niche the business is, the harder it likely is to get off, but there are even exceptions to that. So Sabre, which is one just of a handful of nuclear-powered travel scheduling sites, is unsurprisingly finding it more difficult than, say, a bank--there are lots of banking solutions, and with the consolidation in that industry, there's a ton of upheaval in their systems anyway. IOW, if you're merging BigBank with HugeBank, you've already got a giant systems analysis/merger problem, and if your CxO chooses this juncture to switch to a new platform, that's not necessarily insane. Insurance MIGHT be another case: yes, they have tons of custom logic for policy analysis etc., but a lot of that has likely evolved off of Z already, so at some point it's mostly just the database. There are one or two non-mainframe DBMS out there, so that becomes doable at some point. That doesn't mean it's without risk. And this is where the biggest remaining value of the mainframe remains for most companies: not that it's faster, more efficient, more secure--we can argue about those in various contexts, but it's unquestionable that the squatty boxes have at least closed the gap significantly since the early days of client/server and "the mainframe will be dead in ten years". No, for most enterprises, the real value of Z today is in the captured intelligence/knowledge in those custom applications. Converting your core COBOL z/OS-based system to Java on Windows represents huge risk because of all that captured smarts, that special-case handling. Fred put some of that in on a rainy Thursday afternoon in 1982, and Fred is retired and/or DEAD. And while he knew about it and so did some others, if anyone is still around, they don't remember, and internal documentation of such things is iffy (or it's beautifully done, in BookMaster somewere...). So a port is going to miss that, the spiffy new system is going to misbehave in some subtle way, and it's going to cost money, possibly a lot if the fallout winds up in a lawsuit. This is where a product that used to be a Micro Focus offering (back when Micro Focus existed) and is now a Rocket product can shine: Enterprise Server (ES). I'm not a shill here, honest--I've seen ES in action and now that it's not owned by a company for whom I work, I feel like it's more legit for me to talk about it. ES is built on the Micro Focus COBOL and PL/I compilers for Windows/Linux, and adds emulation of enough of z/OS--JCL (I won't say "JES"), SAF, CICS, Db2--that you can take a fairly vanilla application including its use (that's where the JCL part comes in) and port it without rewriting it. Consider your typical long-time Z shop. They used to have PROFS and payroll and HR and their core systems on the mainframe. All of those have gradually wandered off to Exchange and SAP and whatever except that core system. And now when someone says, "Can't we get off the mainframe?" there's the additional pressure that Fred retired/died and his cohort are gradually retiring/dying, and replacing them is non-trivial. In such cases, ES can allow a reasonable transition to other hardware without all that risk. Yes, I hear you in the back talking about reliability etc., but again, those other platforms have largely caught up. And while that core application is, well, core, it may not actually require 24x7x365 reliability. Historically, while that was achievable, how many systems really met that goal anyway? Monthly IPLs; hardware failures, especially DASD, before arrays; and nowadays network issues that are outside Z's purview anyway--all of these happen. And with most systems off of Z, that 24x7x365 reliability might be less important than it used to be anyway--yeah, it's bad if the core system is down, but if nobody is going to die as a result, then most of the company can continue while it's fixed. Unlike when EVERYTHING was on Z, and an outage meant the whole company stopped. With ES and some replication, one box failing need not necessarily even stop that core application. Cheaper hardware may mean that it's easier to test, leading to better outcomes from updates. Etc. FedEx seems like an example of this: clearly their core applications would be the interconnected scheduling/tracking of packages. I imagine (have no real knowledge) that things like scheduling planes/trucks moved off long ago, and that perhaps when they built the web interfaces, a lot of the user-facing stuff either moved off or at least was significantly front-ended. Maybe the last thing on Z was the actual database of packages; again, there are lots of choices at that point, and if I'd been doing this, I would have built the new system to run in parallel for a while and compared results until I was confident enough, then swapped the "real" use to the distributed version while still running in parallel with a quick way to switch back. In any case, they did it. No, I'm not anti-mainframe (as I've written here before, I've made my living off of it for over 45 years), but this is the reality we're in. Pretending that it can't happen is foolish, and knowing about things like ES may be useful if and when that CxO makes a pronouncement about getting rid of Z. ...phsiii -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of David Crayford Sent: Saturday, November 30, 2024 12:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Heh, "Sabre is Getting Off the Mainframe-One Way or Another" FedEx moved to AWS. ING too. All these smug comments are a bit misplaced. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN