Slashdot Mirror
Microsoft Makes Push for COBOL Migration
geoff313 writes: "It would appear that Microsoft
is making a real push for the migration of existing COBOL applications to Windows and their .Net platform. Micro Focus, a company who makes
COBOL migration products and last year became a member of Microsoft's Visual
Studio Industry Partner (VSIP) program, announced their Net
Express with .Net product, a plug-in to Microsoft Visual Studio .Net
2003. It allows for COBOL code to be integrated and manged with other code in Visual Studio. In an interview with eWeek he declares that 'Micro Focus and Microsoft are bringing the mainframe to Windows and .Net'. This makes me wonder, are there any Open Source projects working to provide for this eventual migration? Gartner estimates that over 75% of business data is processed by an approximately 200 billions lines of COBOL, so
this seems like a huge potential market to lose to Microsoft."
Has anyone used Tiny Cobol or Open Cobol
As long as it works and there are no issues like Y2K why would you get rid of something that works? It's not like new machines wont run COBOL programs.
I work for an insurance company, running a policy administration application running under Windows. We currently administer approximately 150,000 policies, and were recently acquired by another company. They're dumping their mainframe based admin system and we're taking on their policies as well. This system is written in COBOL, and at one time we were using Microfocus COBOL. The vendor switched to Fujitsu COBOL and the next version will be Fujitsu COBOL.net.
Microfocus is a little late to the table.
The system is running of a $40,000 Dell server, and replaced a mainframe that was costing almost $1M a year to lease/maintain. It's very doable.
Information week has an article from Nov. 3, 2003 noting that 38% of Gartner's shares are owned by Microsoft, Oracle, Dell and a few other major players. All of whom would presumably benefit from what Gartner has to "report" about their respective fields of interest.
Considering that Gartner has been charged with bias from some circles already, this can't help things.
Who Owns Gartner?
> Aren't most COBOL applications deployed on big
... It's very rare to find someone writing COBOL code from scratch; it's all based on changing proven existing code and thus carries a relatively tiny risk of problems occurring after deployment. Furthermore, it's quite common to take the output of one piece of COBOL code, and use that as the input for your new set of COBOL code. Add a few generations of this, and suddenly you're dealing with an enormous mass of COBOL code, possibly largely undocumented and written by guys who retired years ago, that you have to port across to get a single piece of functionality working. It's very difficult to even write test cases for this legacy code, since its original purpose may be totally forgotten and the only reason it still exists is to support all the newer code that's been layered on top of it. This is a big factor that tends to be conveniently forgotten by those who think a move off the mainframe to Windows or Unix is simply a matter of time. A change to the .NET platform, or any other platform for that matter, is simply not feasible for the vast majority of mainframe shops on this basis alone. .NET is often seen as a high risk option. Remember, CICS and MVS have been around for decades, and they're known to work close enough to perfectly. For the type of work COBOL is currently being used for, reliability is absolutely top priority; you don't want your huge transaction processing system to go off the air for even a few seconds while your Windows systems take an outage for patches to be applied.
> iron?
That's been my experience too. Most COBOL work being done today seems to be primarily presenting existing data in different formats for consumption by Unix or Windows based systems.
There's no way this COBOL code is going to be migrated off the mainframe, for several reasons:
- it's being written and maintained by mainframe COBOL coders. They have no interest whatsoever in saying it's feasible/viable/cost-effective/... in porting this code to another platform, because doing so would probably put them out of a job
- this code tends to be built on top of old code, which is built on top of older code, which is built on top of
- as this code is primarily involved in presenting data in different formats, this work is best done as close to the database as possible. You don't want to be sending a big wad of data to another system, only to have 90% of it get thrown away and the remaining 10% formatted and consumed. It's generally cheaper to do this on the mainframe
- in the mainframe environment,
That's my take on things, but I'd be very interested to hear from anyone who sees mainframe COBOL code being used to do anything different.
one would be better off leaving it on the mainframe until peices of it could be rewritten in a more modern language.
I work in the health insurance industry. We run millions of health care transactions per day through our mainframes. We use midrange and distributed systems (Sun primarily, along with a few Windows systems) to bring the transactions in the door and do the business intelligence work afterwards. Last year we start our planning to move off the mainframe. It is exactly what you described. Take pieces (the easy ones first) and rewrite and rehost. We probably won't finish the effort before 2008, or so. Of course, our current transactional system has been in place on mainframes since about 1978. We haven't missed a weekly payment cycle in more than 15 years. Our Windows boxes (even the supposedly high availability ones) miss cycles on about a monthly basis. We have no intention of even considering Windows for the rewrite effort. We're looking at Sun/Solaris, IBM/AIX and Linux clusters.
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.
that reason is reliability. if it ain't broke, don't fix it.
note, y2k required fresh re-writes on many mainframe systems, and those old COBOL guys had a field day. but notice too, that they didn't go thru the trouble of migration then, even tho the amounts spend would have justified it!
if it ain't broke, don't fix it!
"You never want a serious crisis to go to waste." - Rahm Emanuel
But this is the standard that we have to adhere to because we provide claims payment, treatment authorization and such for insurance beneficiaries. Our SLA's with our customer only allow us 30 minutes of downtime for the entire system per week. That includes the mainframe sysplex, the point of sale system, the web access for doctors and pharmacies, the interactive voice systems and all of the claims entry points.
It's not about my data center kicking your data center's ass. This is the sort of hardware and software reliability that big data centers have to have. And this whole thread started from the idea that running COBOL within .NET was somehow innovative. The big iron shops (Sun, HP, IBM) have had COBOL migration or rehosting programs for years. I pointed out that the guy who thought this was innovative probably run a couple of windows PC's and a server. While that is necessary in the grand scheme of things, it isn't a really likely place to learn about big, mission critical IT. I used to work for a small business. We provided network services and integrations to other small and medium businesses. I thought I knew what reliability, scalability and uptime was all about until I went to work in a place where people literally might die if the system was down.
UNIX is so close to the mainframe in reliability terms these days that there is literally no way to differentiate. I can engineer a Solaris, AIX or HP-UX system to 5 9's reliability, and have as much, or more, processing power as a mainframe sysplex. But, the problem is all that COBOL code. It has to be moved. The original design of much of the world's core finance and insurance systems happened in the 1970's. The original designers are gone. The code is not well documented or commented because the people who wrote it, for the most part, didn't think it would still be running in COBOL, on mainframes, in 2003. Moving it in one big jump is scary, and high unlikely to happen.
We will move it, because you can't really innovate with COBOL anymore. Programmers are harder and harder to find, the SME's are retiring, and the best and brightest of the new generation are going to distributed platforms, especially Java. So, instead, we will move it one sub-system at a time to a new platform. Either a UNIX or Linux cluster, and the foundation will probably be Java. There is no confidence in the data center in Windows computing. We have had too many bad experiences with the few systems we have tried out. Bad by our standards. Granted, Windows can now achieve 3 9's, with good engineering and a LOT of tender loving care. 5 9's amounts to roughly 5 minutes of downtime per year. 3 9's amounts to roughly 500 minutes of downtime per year. 500 minutes of downtime means we might miss our SLA's for as many 15 weeks a year, depending on how the downtime worked out. That's a lot of lost revenue. And patients who can't get their treatment authorized on time or doctors not getting paid on time.
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.