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."

Comments

Bah humbug...

[__aavhli5779]

Aren't most COBOL applications deployed on big iron?

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 .NET solutions will be deployed on big iron; rather, my assumption is that we are dealing with standard x86 server farms running Windows Server.

Anybody who migrates to .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.

How seriously do you think this will really be taken up? I posit: "not much".

Re:Bah humbug...

[Anonymous Coward]

Yeah, but that mainframe (if it's an IBM/3x0 series) is effectively unkillable, whereas a PeeCee server eventually kills itself with its own heat...

I mean, not to troll, but that $1M is probably worth it. Mainframes are rock solid, incredibly dependable systems. Any PC system, no matter how nice, isn't. Instruction recovery, ensured datapath accuracy, automatic redundant verification... the closest you can get in the PC world is RAID, and that only covers storage.

*sigh*

Re:Bah humbug...

[ericman31]

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.

You're pretty much dead on. Sun and HP systems have had more horsepower than mainframes for quite a while now. They are nearly as stable too. But there's a couple issues:

• A lot of mainframe code dates back to the 70's. Trying to migrate it would be a nightmare. Modular rewrites, one little piece at a time is more likely to succeed.
• CICS, TSO, MVS, VSAM, etc. is dead on reliable. Our mainframe sysplex outages can be measured in mere minutes per year.
• There are simply too many migration scenarios where the system was eventually migrated off the mainframe, but the managers who initiated the migration were no longer managers when it was complete due to budget overruns, delays, and other problems. CIO's learn from this, and aren't willing to go there if they don't have to.

Dell servers running Windows are nowhere the reliability level of Sun/IBM/HP RISC servers running UNIX, let alone the mainframes. Mainframe shops are not willing to risk mission critical money makers on unproven, unreliable upstarts.

Re:Bah humbug...

[llefler]

You are of course, speaking from experience, right?

Not only are nightly batch cycles still used in mainframe environments, but I have also seen them in PC based SQL environments.

And I think you are missing the point; x86 servers may have plenty of CPU, you can even build clusters, but you simply don't have the I/O capacity. Consider a company with half a million 600meg tape cartridges in their library and 5-10,000 of those get cycled every night. Now I haven't been a tape ape for over 10 years, and those are still pretty big numbers.

Re:Bah humbug...

[danheskett]

The thing is you assume that all these places use tapes on a nightly basis when a good number have migrated to other storage mediums.. tapes are not everything..

A lot of mainframes can be replaced with a low-end PC running Linux or even Windows without any noticeable loss of performance.

I've seen $500k a year mainframes (leased, of course) replaced with a pair of $10k IBM x86 servers. Setup with failover in mind one PC could be yanked out and the other taking over the load in a fraction of a second without notice to users.

Saving your boss $480k a year will get you a lot of praise. I know the guy who did it. Look at it this way: they could afford to pay some $50k a year to babysit those two RH servers, buy new hardware each year to do preventive maintenance on, and still have an extra $400k a year saved. Multiply that over a decade, and you're talking the difference between profit and loss, good stock or bad stock.

A lot of mainframes are needed. A lot are required. But most are not.

Re:Bah humbug...

[dperkins]

Umm, Actually, we are currently migrating several tax systems from a government mainframe system to a Sun Solaris system. Mirrored solaris boxes running an Oracle database, mounted from an EMC SAN. IO is not an issue, and we are running Microfocus Cobol for our back-end batch.

I would like to say, however, that much to my disappointment, we will be going forward with .NET in future projects. We have actually taken a look at COBOL.Net from Fujitsu, and though I don't think we will be using it, .NET is where we are heading. Mainframes, however, are seen as the proprietary means of locking folks in, not .NET.

Companies that have been locked into mainframes for so long are trying to escape from that "Big Iron Prison" to Microsoft. Ironic, isn't it? :)

Re:Bah humbug...

[cotopaxi]

I work for a software company that does ERP systems for some niche industries - both the writing and the implementing. All of the business logic is written in Cobol.

Of our clients, nearly all of them used to be on mainframe systems. Over the years, most of them migrated to UNIX(either HPUX, AIX, or Solaris for us). We haven't done a new mainframe implementation in years - all of our current work is on UNIX(bigger more knowledgable clients) and Windows(smaller and much less savvy clients).

We use Microfocus NetExpress on Windows or ServerExpress on UNIX and have for years. We use either Tuxedo or CICS for a TP(yes CICS does run on Windows and UNIX). Not quite as safe as a mainframe, but we've had large UNIX sites experience nothing but small amounts of scheduled downtime over the years.

Now, will .net affect us? Nope. Many ERP systems providers are hugely interested in platform independence. All new development work is being done with EJBs using IBM Websphere's Enterprise suite(which includes CICS as the TXSeries product). I don't think many companies who service large businesses ever want to be locked in to a Microsoft solution, or have to maintain parallel development efforts to support their latest technology.

Re:As much as I hate MS this is very smart.

[ericman31]

Oh please! Sun Microsystems has had rehosting solutions for COBOL on the mainframe to their platforms for years. Look at:

• http://www.sun.com/migration/mainframe/sunps/
• http://www.sun.com/migration/mainframe/

This isn't innovative at all. Unless, of course, the only part of IT you have ever been involved with is PC's running Windows and a couple of small servers and don't know what the data center is all about.

Don't hold your breath...

[Dinosaur Neil]

Migrating COBOL apps to PC platforms won't happen on a large scale for two reasons:

1. Reliability - We used to "reboot" our mainframe once a month, whether we needed to or not. No way will mission critical applications end up on any system that dies on a daily/hourly basis.
2. Inertia - The reason for all those lines of godawful COBOL code is that it works. It runs and doesn't cost anything more to keep it running (at least not on the applications side of things; for some reason support time and effort doesn't count, no matter how much is required). There is a strong "if it ain't broke, don't fix it" mentality in the people that decide where to allocate programmer time.

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.

Inertia, maintenance and programmers

[Anonymous Coward]

Just some thoughts,

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 .. who would really want to do this for 30 year old code that works fine where it is.

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.

This is not new news...

[madmarcel]

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 ;)

Visual Basic and Visual C++ where very distinct languages. The .net languages are not.
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 :)

The issue is not COBOL..

[Garg]

As a guy who's done mainframe programming for 23 years, here's why I think this won't have much of an impact.

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:

• Batch. These are the payroll-type systems that run in the background, are are mostly ignored by people claiming to be able to migrate systems. The thing is, these systems are full of extensions for mainframe-type filesystems or databases, like VSAM or IMS. So while MicroFocus handles some of that stuff correctly, it won't handle it all.
  
  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.
• Online. These programs run under CICS usually, sometimes IMS or (more rarely) non-IBM TP monitors. These systems have all sorts of calls specific to CICS or whatever. (For example, you can't read the file system directly under CICS.) So the Windows COBOL things usually follow the 80/20 rule here, as far as what will work... but the 20% will kill you. Things like background tasks to communicate with remote systems over an APPC connection. (If that last sentence made you go "huh?", you may realize it's what you don't know that will doom a project of this sort.)

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

Re:As much as I hate MS this is very smart.

[molarmass192]

the only part of IT you have ever been involved with is PC's running Windows and a couple of small servers

Although I don't like stereotypes, you've just described at least 3/4 of the posters on Slashdot with that one.

Without JCL (& other stuff) it just won't matt

[PinchDuck]

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.

If FORTRAN is a forcast ...

[twitter]

M$ COBOL will be a one way sink that won't last long. That's right, M$ I still remember how you waded into FORTRAN, added nifty little toy tools without getting the basics right and then sold it like a hot potato to Digital where it rested in peace. Another fine member of the Visual Studio. Pththth-fit!

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.

Economics 101 people!!

[DukeyToo]

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.