Sunday, January 31, 2010
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!
Monday, January 18, 2010
People don't search the web about COBOL much - why? Because few people publish anything about COBOL - let's fix this!
I have been busy posting to 'The Code Project' a few articles on COBOL over the last two months:
- Using Tuples to Synthesize Polyadic Returns in C# and COBOL
- A Comparison Of .net COBOL, Visual Basic and C#
- A SVN Browser Using Scraping and WinForms in COBOL for .NET
- Calling F# from COBOL and Back Again
- Anonymous Delegates In COBOL for .NET
The Code Project is a Windows centric community code site. The interesting thing is that (remember that these have only been up for a few weeks) these posts have attracted over 7000 (yes - seven thousand) views!
If you love COBOL, write posts. People are interested. Post them on blogs, post them on code sharing sites. Even send them to me and I will post them (for details - just comment on this post).