As many already know, the most expensive item in the data center is usually the mainframe and everything that goes into keeping it alive and well, processing the millions of rows of data and transactions each week. If asked what sound most exemplifies their data center, the CIO probably wouldn't pick the sound of a Ferrari. Or the sound of an ever reliable diesel engine. Nope. Not even close.
It would most likely be the sound of a vacuum cleaner going full tilt trying to inhale that sock someone left under the edge of the couch. As far as the CFO is concerned, these environments suck the money right out of the company coffers. Keeping the big iron up and running requires some serious funds.
These “enterprise platforms” allow those same companies to realize the profits the shareholders care so much about. Without these enterprise class systems created around the mainframe platform, there would be no company. A catch-22 it would seem.
The problem is that many people confuse the platform with the systems which run on them. And the largest portion of these applications are written in COBOL. So, mainframe = bad and COBOL = mainframe. Then many confuse the two and come to the conclusion that COBOL = bad.
A common theme I've heard over the years is to replace the platform AND the applications. This is how folks like SAP acquired such a toe-hold in many corporations. They sold CIO's on the idea that to reduce costs in the long term you had to do both. Bang, that COBOL shop goes the way of the dodo.
But I have yet to hear about a single company who implemented SAP or any other package on time and under budget. How these packages keep getting sold as replacements to the tried and true COBOL applications is beyond me.
Others have been pitching that they can rewrite these massive processing engines in another language on a lower cost platform quickly. And the initial prototypes seem to indicate this can indeed be done quickly and at a low cost. An uninformed decision is made and another COBOL shop bites the dust.
On a rewrite, what usually ends up happening is that the first prototype works well, but when they start trying to build a complete system, reality sets in. Many find it is very hard to recreate something in the projected couple of months which took 20 years to write. Going with a package or rewriting everything costs more than most folks realize. But these aren't the only options and COBOL doesn't have to necessarily die to help cut costs.
Companies can swap out the platform without swapping out the applications. The COBOL, PL/1, CICS, DB2, IMS, JCL applications can run just fine on platforms such as Windows Server 2008 R2. No need to throw out the baby with the bath water! 20 years ago, you had little choice. Nowadays, companies have options.
You've seen some of the posts by Alex, Rick, and myself about the “new” capabilities of the environment. In my next few posts, I'll discuss some of the features which allow you to move your existing mainframe COBOL applications off without rewriting them. Let me know if there is something particular you want me to focus on. Stay tuned!
Posts
And the definition of a "legacy system?"
ReplyDeleteOne that works.
I am very interested in what you have to reveal. I have yet to see unedited ACTUAL mainframe COBOL run on a PC (or like system) natively.
ReplyDeleteI'm also interested in how you would implement a VSAM-oriented shop on client-server architecture (I notice VSAM is something you left off your list).
Thanks,
-Mike
Hey Mike, not a problem. There are always some sort of changes to the overall application, but believe it or not, most changes have to be made due to the supporting systems, not the mainframe COBOL application.
ReplyDeleteMost migrations I've been involved in are direct moves, but there are always certain application changes required at some point,even if minor items.
You've given me an idea... I'll post some of the kinds of things which have to be "focused on" during a mainframe migration.
As for VSAM yes it is supported. This is because Windows, Linux, UNIX all support indexed files. And products like Micro Focus provide support so that the applications don't know they aren't accessing VSAM. I'll see if I can put some stuff together on file conversion as well.
Thanks for the feedback!!!!
My COBOL apps (SMB accounting and info management) have been running for 26 years, and I have continually modernized them. They now not only are GUI, but also run on a web server (using Java Web Start), and I have been unable to find anything that could be used as a suitable replacement.
ReplyDeleteWhen I worked at Moore Business Forms (remember them, more later), they tried to put in SAP to replace their Legacy systems. After $1 BILLION the gave up. That's right, they gave up. NOT A SINGLE LINE OF SAP CODE EVER REACHED PRODUCTION MODE. They had 11 SUN Micro servers. I asked what the difference was between a mainframe and 11 serves and I was told the mainframe had ONE Operating system, the servers had 11 operating systems. After the company ran through it's cash reserves they were bought by R.R. Donnelly. That's what SAP will do for you.
ReplyDeleteWell, I think my point has been missed. Micro Focus has as part of its suite a sort-of mainframe emulator, does it not? So if a "compiled" COBOL program must be run in an emulation mode, that's not a direct port of the code, is it? And it's not compiling to run natively on the smaller platform.
ReplyDeleteJust what sort of "indexed file" is it that Windows (et al) support?
I assume it's a type of layer that fools the COBOL application into not knowing that it's not using VSAM. But this layer surely adds complexity (read: CPU cycles) to the execution, right?
In the end, this doesn't seem near as portable as, say, Java. Or even Perl.
In fact, I have on my work PC a Java app that was written for the mainframe... unaltered... runs perfectly on both platforms. I've just never seen COBOL come anywhere close to that.
To me the weak spot is JCL... mainframe batch applications depend on it so heavily, and the COBOL has to be written to the JCL just as much as vice-versa.
-Mike