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."
hog wash (Score:3, Interesting)
What are the Linux COBOL solutions? (Score:5, Interesting)
Why would you? (Score:5, Interesting)
Re:Bah humbug... (Score:5, Interesting)
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.
Speaking of Gartner... (Score:5, Interesting)
Considering that Gartner has been charged with bias from some circles already, this can't help things.
Who Owns Gartner? [informationweek.com]
Comment removed (Score:2, Interesting)
Re:Bah humbug... (Score:5, Interesting)
> 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.
Re:Yikes (Score:5, Interesting)
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.
Re:Why would you? (Score:5, Interesting)
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?
Re:Bah humbug... (Score:1, Interesting)
Mission critical applications can be run in a windows environment. In 4-5 years I wouldn't be surprised if the hardware will be at a point that it can match the performance of a mainframe, for much less cost.
if it ain't broke, don't fix it! (Score:5, Interesting)
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!
Re:if it ain't broke, don't fix it! (Score:2, Interesting)
Re:The issue is not COBOL.. (Score:3, Interesting)
I'm a unix guy, I have a huge financial incentive to support this kind of migration. But it's not going to happen. At the bank where I work, all new development is Java on Unix, that's fine and dandy but the backend systems with their huge Multi terabyte VSAM files won't be rewritten any time soon.
OpenVMS on Intel (Score:1, Interesting)
Support (Score:3, Interesting)
Re:Bah humbug... (Score:1, Interesting)
First - contrary to much of this thread, Microsoft **is** gradually building Mainframe-scale capability; usually with help of knowledgeable partners like Unisys, Fujitsu/Siemens, NEC, and others that (a) are committed to Wintel and (b) know how to run Mainframes (theirs, not IBM's). Yes, HP may finish the OpenVMS port to Itanium, which would allow VMS Clusters to begin migrating from Alpha to Itanium in 2005, but this only benefits Intel, not Microsoft. Microsoft is likely building the same capability into Windows 2003 Server Data Center Edition; remember - David Cutler was the original architect of VMS and VMS clusters. What has he been doing the past 4-5 years? What I read was he's the owner of the Windows-64 Server OS evolution at MS. So having "Mr Cluster" working on this process obviously helps me conclude MS will eventually have this at the high-end. Those 16 and 32 way Itanium servers that may eventually show up (as well as similar scale AMD servers) - if enabled with a VMS-style robust cluster capability - would get MS close enough to the mainframe to make this work for some customers.
Second - Yes, lots of the old-iron programmers were "recalled to active service" to do the Y2K fixes. But will they be there in 2006-2007? Over the next 3-to-4 years, how many will have gotten too far away from work (via retirement or death) to be able to come back for more? Microsoft is just dealing with the reality of the past 20 years of teaching students C, C++, VB, and now Java. We have started to lose the COBOL critical mass of programmers from the 1960's to the 1980's to _age_. How many of the current unemployed programmers out there would be willing to retool themselves for old-iron programming (not just COBOL, but also understanding JCL, CICS/ISAM, IMS, and all the rest)? Any takers? Of course, the famed "India or Eastern Europe/Russian offshore sites" might develop or already have developed this capability, which could dent the MS strategy some.
Bottom line here is this is just another arrow in the Microsoft quiver in its fight to attack that last bastion of computing it hasn't been able to crack - the IBM Mainframe. If it is serious about migrating mainframe customers to
JAAC
(just another anonymous coward)
PS - interesting that this announcement gets made the same week as IBM is going to announce a new Linux-on-Desktop policy. Standard old stuff - you attack my core strength (Microsoft at the Desktop) and I will retaliate by attacking yours (COBOL on the IBM Mainframe).
Re:Oh no! (Score:1, Interesting)
In My Day... (Score:3, Interesting)
oh, and btw, I'm not a COBOL programmer. just someone who respects them enormously. Props to the host team!
tims
Re:As much as I hate MS this is very smart. (Score:5, Interesting)
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.
Re:Bah humbug... (Score:3, Interesting)
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.
Those numbers are abnormal. If they were properly utilizing that $500k mainframe, it wouldn't be possible to replace it with a $10k x86 box. $10k doesn't buy much of an enterprise server. Our 4 processor Netfinity SQL server alone cost several times that much.
Companies that buy/lease 390s tend to need the capacity. Otherwise they're using AS/400, Sun or Alpha, and the hardware costs aren't enough higher to outweigh the fragile nature of x86 hardware.
A lot of people here seem to assume that mainframe means it was purchased in the 70s and hasn't been upgraded since. The only places I've seen that to be true are in universities and non-profits.
Re:Bah humbug... (Score:2, Interesting)
Re:Bah humbug... (Score:1, Interesting)
Cobol people do want to port this to IBM's Linux/Unix,or SAS as its dead easy, but the Microsoft people a scared about loosing their jobs, as java and websphere work on a mainframe. Check out IBM's web site - which delivers web pages done an a mainframe - and unaffected by viruses, that scales and is reliable.
On mainframes, patches can be applied without stopping anything, and SUN is very good too. Windows patches, however take hours.
Cobol programmers do what they are told. Thats more than you can say about
Re:Bah humbug... (Score:2, Interesting)
True. Which is why, I suppose, Microsoft used to market a COBOL compiler many years ago (1990, I think I last saw it).
Looks like they've revived the project...
And worse... (Score:2, Interesting)
I've seen a number of high-profile sites where 30-year-old binaries are still in use too; in some cases the source code was lost years ago, and the things were only maintainable by directly editing the object code.
It's not much fun to do that with COBOL compiler output, but it's do-able and saves a lot of time.
Yes, I'm that old. Want to make something of it? :-D
Solution: (Score:3, Interesting)
From what I can see, Cobol is a procedural language, so it could be easily translated to C++ (no need to uses classes, just the functional part).
There is already a GCC backend, which means that Cobol maps to C++ perfectly.
And those 'goto' statements can be made as functions.
The translator app should also allow which database engine and library to use; the Cobol code that does database I/O would be replaced with calls to this engine.
This translator app could be made as backend to GCC: the Cobol compiler could produce C++ code instead of assembly code.
Re:old-skool programming (Score:3, Interesting)
In 20 years my infant son will look at my code and "think WTF is this antique?"
But back to your point... a company with, say 2 million lines of cobol running on a mainframe that runs almost flawlessly. No major problems. Now, rewrite that code in something more modern, and redeploy on a more contemporary platform.
How long will this take? How much will it cost?
More importantly, how much more bread will it help that regional bakery (for example) sell?
Re:Bah humbug... (Score:3, Interesting)
Re:Bah humbug... (Score:3, Interesting)
Oh I think they could, just write the code in COBOL and you can be pretty certain that it will be fragile and bug ridden, particularly if you run 30 plus year old code that nobody has the source for.
Mainframe hardware can be pretty reliable - particularly if you compare against some of the crappy stuff sold by wannabees. But it is certainly not infalible and you can certainly get high end intel class boxes that are easily a match reliability wise. As for mainframe O/S being reliable I have to snigger there, there is no way to know how reliable MVS is, the operator will make so many errors that any the system makes will be lost in the noise. Reliability should be measured for the system as a whole, MVS creates so many opportunities for an operator to botch things up it isn't funny.
Microfocus has been in the cobol business for at least 20 years, what the story is about is being able to use Visual Studio as a development environment. That is pretty big news since only a complete masochist would want to develop code in an MVS environment. Unless you have tried Visual Studio, don't knock it, it leaves emacs in the dust.
I am not sure that Visual Cobol is going to be a great programming environment, a lot of the Visual C# features are made possible by the language design. But if you are going to endure the misery of cobol it is probably the best way to do it.
I suspect that a fair number of programmers would use the package to gradually migrate systems from Cobol on Mainframe to Cobol on dotNET to Cobol with SQL backend on dotNET to full C#/Java code with SQL backend.
They can keep it (Score:3, Interesting)
And I gotta tell you folks, Microsoft are welcome to it. It's a God-Awful language fit only for financial and other business applications. And for those who think financial applications are trivial, hence worth the pain of COBOL's God-Awfulness - think again. Financial apps are always having to react to changing rules, regulations and the latest fad from sales and marketing. Believe me (I have done both) molecular simulation is EASY compared to a large corporations general ledger. At least the value of PI never changes.
Example: A well-known US retail company's W10(? - USA tax) program comes to mind that I worked on briefly before skilfully offloading to some other poor sucker.
Check this out:
No specs
No doco
Some of it was in mainframe assembler
Object orientated? ha ha ha
Structured programming? oh my god ha ha ha
Code re-use? stop it! im pi**ing myself!
Variable names like W88_REC (erm, thats it) and code that was all over the place. GOTOs. GOTOs!
Example - every year the US states tinker with their tax levels. Sometimes, especially in the smaller states one guy is taxed in one state, but works in another, except on wednesdays if its raining and so on. So we had code everywhere that looked like this:
IF WS-STATE = 'TX'
THEN PERFORM U201-STATE-TX-W10
ELSE
IF WS-STATE = 'NH'
AND WS-HOME = 'NY'
THEN...
(and so on for 48 other states)
I think you get the picture.
Screw that.
Then there is that reliability issue. Microsoft OSs struggle to match Linux/BSD when the going gets a bit sticky. The level of reliability expected from a mainframe is another world altogether. I remember an old story about an IBM engineer who somehow managed to yank a whole chunk of memory from an OS390 core. Apparently that old chunk of iron soldiered bravely on for TWENTY minutes before ops' screens went red and it finally gave up the ghost, having cleanly swapped out all running processes and parked all the disks. Now THAT is a stable operating system and Im not even an IBM fan.