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."
Aren't most COBOL applications deployed on big iron?
.NET solutions will be deployed on big iron; rather, my assumption is that we are dealing with standard x86 server farms running Windows Server.
.NET may find their projects more maintainable (if only because the number of COBOL coders is declining fast), but because of the underlying platform, they'll be introduced to a world of hassles, too, and I doubt businesses with mission-critical applications (like the big banks and insurance companies and what-not currently using COBOL on mainframes) will go for that.
I doubt any Microsoft solution could honestly compete with the scalability and reliability of a true mainframe, and it doesn't state anywhere within the article that these
Anybody who migrates to
How seriously do you think this will really be taken up? I posit: "not much".
You have to admit, this is the most innovative thing Microsoft has done. Ever.
--ken
Bitcoin pyramid: Join here: http://www.bitcoinpyramid.com/r/1427 it's FREE!
Most places running COBOL apps are doing so largely because the stuff "just works" and they have the "if it ain't broke, don't fix it" attitude about it.
.NET!" Still, you can't blame Microsoft for trying. They're the experts at finding untapped markets and selling to them. They may even have moderate success, selling complete migration solutions to govt. agencies. "We'll contract out developers to move all those apps over to our new server farm and sell you the whole thing for price X!"
In many cases, the biggest concern is that their legacy hardware will become so obsolete that they can't get service contracts or replacement parts for it anymore. If/when it reaches that point, they're probably going to consider it time to redo *everything* from scratch -- implementing new software along with new hardware to run it on.
I don't think there's really much of a market out there saying "Gee.... if only I could migrate all of these COBOL apps on our mainframes over to Windows and
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
I don't really think MS has much of a chance of changing the big boys' COBOL machines. Sure they could do it faster, cheaper, etc., but given the real need for stability in the traditional cobol marketplace, wherefore MS ?
The only place I've seen banks roll out MS apps are in non-mission-critical systems (bank-staff desktops), although WinNT does seem to run Natwest's ATM machines. I've seen a blue screen of death on them a number of times, so maybe MS aren't so fanciful an option... Damn!
Naah, overall I can see the "client" (you have no power) machines running windows, but not the central (we are the business) machines getting within retching distance of windows....
Simon.
Physicists get Hadrons!
And Microsoft advertises of Slashdot.
So what's your point again?
That's right.. it's not a huge potential market to win - it's just another huge potential market to lose to Microsoft.
Is that really the main motive to start development on something ?
If the opensource developers were to 'lose' something to Microsoft due to lack of development by said opensource developers, then that's a deserved loss, no ?
In fact, if said opensource developers had no interest in developing said something before, why would they even care if 'they' lost the market for it to another developer - be it Microsoft or anybody else ?
That said, further comments already pointed out that such projects do exist, and thankfully not just born out of an interest to spite Microsoft.
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.
AFAIK when M$ developed .net, they studied a large number of programming languages (java, c++, cobol, etc) and then developed the .net languages from there. Now, all the .net languages are meant to be able to be compiled and executed using one single run-time environment, so in order to get that to work the .net languages have...'converged'. (Must avoid using the word 'assimilated' here ;)
.net languages are not.
:)
Visual Basic and Visual C++ where very distinct languages. The
VB.net has become more like java. C# has become more like java, etc etc. I have no doubt that COBOL.net will be exactly the same.
The point is: You cannot take a 10 year old COBOL program and expect it to be able to compile using COBOL.net. You will probably have to rewrite the entire application into a sortof half mishmash of COBOL, VB and java ( -> COBOL.net
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
> Punch Cards: No more worrying if that last CD backup you did of your system is
> really readable.
If someone produced this method of backup it would be funny twice. Once as soon as it was released, and secondly in 100 years time when it's the only computer output from 2003 which is still readable (Actually, the joke might still be funny in a few thousand years time).
Pascal is not just syntax. There's a lot of careful language design behind that cute face.
It's not a coincidence that Pascal compilers are faster than C ones. And, for more genius work, check Oberon.
I highly doubt M$ is able to understand the principles behin Pascal, but if they did, they would not agree.
xSeries (x86)
pSeries (RS6000)
iSeries (AS/400)
zSeries(the venerable s390 mainframe)
It's a pretty compelling story for producing cross platform, scalable applications while still making the best use of your current hardware investment.
I have Cobol Binaries that still work unchanged, 30 years later. They get written once, then forgotten because they just work.
.NET.
OTOH MS is the opposite of maintainable - things MUST be rewitten and recompiled yearly, and tested frequently with near weekly patches. What a merrygoround.
IBM's MVS is low, low cost, and you NEVER have to rewrite, retest and migrate the application yearly, if you went down th MS path.
Why would step onto a upgrade treadmill, with open ended costs. Try getting MS to commit to binary backward compatibility for more than 5 years.
The real value of COBOL is that business rules are neatly locked up, and stable and in one place. Swapping one mainframe for 1600 MS servers will devalue business efficiency by being lost in an ocean servers, and that re-development and upgrade work overshadows core business activity that really brings in real revenue.
There is no shortage of COBOL coders - but a shortage of managers who seek and reward those with true maintenance skills. ie porting COBOL, or VB5 apps to C++ or C#, would also be cheaper and more enduring than
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.
MicroFocus has been doing COBOL on Microsoft operating systems for years.
.Net... If, in 5 years, Microsoft announces a .NetNG or .Net2008 or whatever then MicroFocus will follow.
.Net platform is sufficient to make people jump where they didn't jump before.
When Microsoft went GUI, so did MicroFocus. When Microsoft went 32 bit, so did MicroFocus. Now Microsoft is going
This is a "migration path" that has been open for a long time. I seriously doubt that the mere ability to target the
Anyone tempted to migrate from their current platform and tools should look at the way things turned out in scientific computing. Efforts like f2c and g77, the GNU FORTRAN compiler, are far superior. Libraries available as Debian packages are also great. The differences are only getting larger as more people are attracted by the tools available. And yes, you can have a beowolf cluster of those. Microsoft had it's ass handed to them.
Friends don't help friends install M$ junk.
It's always funny to me how much most managers in our field consider LANGUAGE to be the barrier to most tasks, when my experience it's really more a matter of knowledge of the type of code you're interfacing.
If you've written procedural code to process transactions in any language, from C to FoxPro to bleedin' VB Script, you should be able to manage COBOL code to process them with a good book and about a week's worth of "high error hacking." The language isn't the problem...it's the type of business logic employed, the type of parsing, the tricks used in that type of programming that really hold you up. The language is just a red herring.
And yet, the first thing people ask you is, "Do you know XxXxX language?" What they should be asking is, "Do you know a language LIKE XxXxX and have you experience in the field of YyYyY?"
Hiring based on task and not on "langauge" is something the industry is just now coming around to, and I think it's due to years of C programmers forced to sit on their thumbs because they knew how to write printer drivers but had never opened a window in their life.
Hey freaks: now you're ju
Unfortunatly, C# is tied to the platform. The mono project is trying, but most of your .NET class library is not going to be ported by Microsoft to linux, so I don't think that .NET will help you much.
Now, I FAR prefer C# the language to Java the language, but C# is tied to a platform.
If I have nothing to hide, don't search me
The Machines dealing with my water, power and banking were using this code in the 1970's and they still are.
It's cheaper than doing it the BillG way.
Message from earth to BillG and MonkeyBoy.
Before you start this battle it's over already.
These guys shilling for you on this are wasting their time.
If you don't like what I write don't be a CS and mod it down. Refute it.
Yea I can't spell. So what is your point?
"Lazy" doesn't come into it - you'd be incompetent if you suggested someone rewrite a working system if the only reason is some perceived notion that the language is outdated.
Cant these bastards leave anything alone? Do they have to conquer and destroy *everything*?
We don't need them anywhere near COBOL. They have no business here. COBOL is stable,
proven, supportable, and run on REAL machines.. not kiddy toys.
Someone needs to take these people out before they assimilate the entire planet. Someone needs
to start at the top, if you get my drift
---- Booth was a patriot ----
All of the arguments about I/O, porting code etc are pointless, because it eventually comes down to economics. If a company is spending $1,000,000 per year maintaining a mainframe, with code that can no longer grow, then there will come a time when they can no longer be competitive - they will have a huge overhead compared to their competitors, and will not be able to respond to market changes.
Mainframes *will* go away, *except* where there is not enough competition, or the cost of the mainframe is small in comparison with other cost centers.
I think that big banks will keep their mainframes, but eventually smaller, more agile banks will grow enough that the bigger banks can no longer compete. Then the big bank will either migrate or die.
Most writers regard truth as their most valuable possession, and therefore are most economical in its use - Mark Twain