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

Reply via email to