Microsoft Makes Push for COBOL Migration 487
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."
Bah humbug... (Score:5, Insightful)
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".
As much as I hate MS this is very smart. (Score:2, Insightful)
--ken
Yeah, this isn't so interesting, really. (Score:3, Insightful)
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
Re:As much as I hate MS this is very smart. (Score:5, Insightful)
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... (Score:5, Insightful)
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.
Market analysis or wishful thinking (Score:3, Insightful)
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.
Re:Yeah, this isn't so interesting, really. (Score:3, Insightful)
If you check out Sun, you'll find that they still sell parts for even their oldest systems. That and more is what the mainframe market is about.
Re:Speaking of Gartner... (Score:1, Insightful)
So what's your point again?
interesting mentality (Score:3, Insightful)
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.
Re:Bah humbug... (Score:3, Insightful)
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*
Inertia, maintenance and programmers (Score:5, Insightful)
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.
This is not new news... (Score:5, Insightful)
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
Re:Bah humbug... (Score:5, Insightful)
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.The issue is not COBOL.. (Score:5, Insightful)
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
Re:As much as I hate MS this is very smart. (Score:4, Insightful)
Although I don't like stereotypes, you've just described at least 3/4 of the posters on Slashdot with that one.
Re:Bah humbug... (Score:3, Insightful)
Re:The Latest From Microsoft R&D... (Score:2, Insightful)
> 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).
Re:Oh no! (Score:1, Insightful)
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.
IBM Makes Use of Linux (Score:1, Insightful)
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.
Re:As much as I hate MS this is very smart. (Score:3, Insightful)
If it makes you happy. But, remember those 200 billion lines of cobol? Those run in data centers that have mainframes. They run primarily banking and insurance transactional systems. Too many people make comments on here whose "IT experience" is limited to an SMB with 5 PC's and one server. You know what our Unix and Windows systems do? All the peripheral stuff that isn't mission critical, that isn't about the core transactions. Our mainframes run our daily and weekly transaction cycles and have been doing so for more than 25 years. They do it efficiently and well. Our enterprise is about moving those transactions through the system, day in and day out without fail. Reliability has to be measured in 4 and 5 9's. Show me a Windows shop (yours included) with 5 9's reliability on their core systems? Our core transactional system has not missed a cycle in more than 15 years. With major system enhancements due to state and federal regulatory changes, with Y2K, with HIPAA.
Low Cost, Works unchanged, 30 years later (Score:2, Insightful)
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
Re:Bah humbug... (Score:3, Insightful)
Not all mainframe applications run on mainframes because they need the power and scalability - a whole lot run there because they were written when the mainframe was the only game in town. I'd bet that a vast majority of legacy applications running on mainframes could easily run on Intel servers without breaking a sweat.
Without JCL (& other stuff) it just won't matt (Score:5, Insightful)
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.
Re:Bah humbug... (Score:3, Insightful)
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.
Microsoft did this? (Score:1, Insightful)
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
If FORTRAN is a forcast ... (Score:4, Insightful)
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.
Comment removed (Score:4, Insightful)
Re:Why was COBOL so prevalent in the first place? (Score:3, Insightful)
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.
Re:Bah humbug... (Score:3, Insightful)
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... (Score:2, Insightful)
Re:Bah humbug... (Score:3, Insightful)
Re:.NET and C# (Score:3, Insightful)
Now, I FAR prefer C# the language to Java the language, but C# is tied to a platform.
Comment removed (Score:3, Insightful)
20 years (Score:2, Insightful)
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.
Re:old-skool programming (Score:3, Insightful)
"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.
Re:Bah humbug... (Score:3, Insightful)
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
Grrrrr! (Score:3, Insightful)
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
Economics 101 people!! (Score:3, Insightful)
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.
Re:Bah humbug... (Score:1, Insightful)
IBM do very little to deal with this problem aside from creating some 'me to' products that do more to hurt the small vendors that they do to drive the big vendors prices down. They could, for instance, create a special licence to allow developers to run modern zOS on the x86 Hercules emulator. Then all those retired sysprogs on IBM-Main could get thier hands dirty creating cheap systems management and monitoring products.
I think the most likly scenario for the 'death of the mainframe' is to have complete redevelopment projects running Linux on zSeries hardware.
Companies that seriously run mainframes (think Visa, major commercial banks and stock exchanges) do millions of dollars worth of transactions per hour (or even per minute). Moving from sysplexes with zero downtime to server farms just isnt worth considering when even a few minutes downtime will swallow your cost savings.