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."
Microsoft Visual COBOL++.NET 2003
Available 3rd quarter 2005. Look for Visual COBOL# in 2007.
His name was Robert Paulsen.
Has anyone used Tiny Cobol or Open Cobol
This is just going to result in the resurgance of COBOL! Not the migration away from it! BASIC was literally almost DEAD until microsoft came out with Visual Basic. What do you think this will do for COBOL!
I DO NOT want to have to debug visual COBOL!
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.
Migrating COBOL apps to PC platforms won't happen on a large scale for two reasons:
I worked on the support side of a mainframe for sixteen years and my experience was that, so long as the reports showed up on the users desk in the morning, there was no problem no matter how many problems there were. Why would anyone invest any time and/or effort fixing something that "works" when there are so many newer and more interesting ways to waste money and make life harder for the support staff...
Good thing I'm not bitter.
"I'm a scientist! I don't think, I observe!" - Dr. Clayton Forrester
> 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.
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.
:-)
This issue is hotly debated at many medium and big companies and organizations. Their biggest fear seems to be finding developers who know mainframe issues. There is a lot of Go-to code and JCL subtleties, for example, in these programs. Go-to programming and JCL is not tought in the schools, especially hacky constructs left over from the 60's where every byte was expensive. Imagine a class called "Go-to Techniques 101"
However, there seems to be a movement in India to create mass production "Mainframe Diploma Factories" that could potentially replenish, or even flood the mainframe market the way they did with web and client/server stuff.
Thus, mainframe labor future is fuzzy. But, insn't the future of ANY technology somewhat fuzzy? Do you really think Java is the final word on programming languages or the final fad?
Table-ized A.I.
Just some thoughts,
.. who would really want to do this for 30 year old code that works fine where it is.
..
1) Migration assumes that, the source code is available (in some cases it it may not be, but businesses will still run the program as it works, and wont spend good money recoding something that is not broke)
2) The target system behaves exactly like the source system. If not then you are redeveloping for the new system
3) Performance. Mainframes may have less relative power than some PC's or servers, but what they do they do well. (Would you trust printing bank statements for all your customers on a Windows machine ?). Our old mainframe used to run 500 users, and had less power+disc than my Windows XP machine. Can I run 500 users on this PC ? No, certainly not under windows (any varient).
4) Reliability. Most cobol applications (one assumes) are running on mainframes (or super minis). As such uptime can be figured in months, (not days as a certain Software Suppliers average uptime for web servers is). With some runs of cobol programs taking days, do you want to run them on something that might crash half way through.
5) Functionality. Yes, some of the functions of some cobol programs could be re-developed in less time/space than they currently are. There are reasons people may not redevelop. Some are for cost. The old adage "if it ain't broke, dont fix it" applies. The code still functions, dont frig with it.
6) Code size. Older mainframes optimised their code very very well. Can you honestly say that modern compilers (ie MS) do so as well? Whats the odds that the 50KB cobol program will be 5MB when recoded, with DLL's and pretty graphics.
7) Other features, such as use of tape drives to read data from. Disc drives that do hardware searching for you (ie ICL mainframes had CAFS, which the controller was given selection criteria and it read the disc for data matching). Such technology is not available on modern PC's or Servers "off the shelf". Thus there may be hidden costs in duplicating the environment, or even migrating the old data to a new environment.
Where I work, we are leaving old systems where they are. New replacements are purchased that have the duplicated or similar functions. It is in most cases not cost effective to "port" old code over.
finally
8) Programmer availability. How many now learn cobol at school/college/university ? most are into Java, C++, etc. Who wants to learn a dead end language when you can have a nice language that is more modern and will earn you money (and look good on your C.V.) Cobol programmers are a dying breed.
First, you have to understand this isn't simply an issue of porting something from one platform to another. If it were, it would've been done a long time ago. Anybody else remember when industry pundits were talking about the last of the mainframes being unplugged in 1999 so we wouldn't have to deal with with Y2K? Sure, a few places migrated off the 'frame, but not many. And I would argue that any company capable of doing so, did so before Y2K.
Basically, there are two types of COBOL systems on the 'frame:
And if it did, what have you gained? I've heard it said that if Windows is a car, UNIX is a racecar... and z/OS is a semi. While Intel or minicomputer (sorry, that's prbably an outdated term) systems can match mainframe MIPS, they can't match its throughput. So suddenly your batch payroll that ran for ten minutes on the 'frame and churns out the paychecks takes all day. Don't think many companies will make that trade.
And the open-source COBOL efforts handle none of the batch or online extensions, so they're almost useless for migrating any of these systems.
So basically you undergo a huge, years-long set of projects and by the time you're done, you may have something that's cheaper, but is most likely just less reliable.
Garg
Garg
Alumnus, Xavier's School for Gifted Youngsters
If it keeps you in a job, don't fix it completely.
On the eve of the New Year 2000, an old programmer went out of his house to go to a party, but was run over by a bus before he could get there. His vision went dark, but then he saw wonderful white light and people in white clothes leaning over him.
"Where am I?" he said.
As soon as he spoke, everyone started cheering and congratulating each-other.
"What is going on?" he said, amidst the brouhaha.
"You see, this is many thousands of years after your time," told him one man in a white labcoat. "The medicine has made huge advancements, and now we are able to revive people who have died millenia ago."
"Wow," said the old programmer, "this is really great. But why me?"
"Well, you see, this is the year 9999 -- we are facing the Y10K problem, and your resume said that you know COBOL..."
If you open yourself to the foo, You and foo become one.
Unless MS and MF have created a really good replacement for JCL, and the ability to seamlessly convert between EBCDIC and ASCII on the fly, and seamlessly access all the data stored in all the DASD in all the datacenters, gin-joints, and big-iron holdout citadels spread throughout the world, it just won't matter.
JCL is the biggest holdup, I would think. COBOL programs perform several steps to a piece of data, kick out output files, and pass control to JCL, which, depending on the return code of the COBOL, will call one of several different alternatives. Having one stinking program run on your PC and having to hand-code all the JCL into batch filesis a massive waste of time. Not to mention that JCL is far more robust then an MS-DOS batch file. Finally, most PC's just don't have the throughput to match an IBM Mainframe with DASD on channel. Finally, you can tell an IBM shop that Windows is far more stable then it was 10 years ago, but it still doesn't compare to a mainframe for reliablility _and_ stability. A Windows server with five 9's reliablity isn't worth shit if the registry is corrupted. That just doesn't happen on mainframes.
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.