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."
Many of the old COBOL applications rely on other components of the IBM mainframe environment. CICS, IMS, MVS etc. are often required. It is not just a matter of compiler quirks. The entire environment would need to be emulated. Not trivial.
COBOL histories can be found here and here. For quite a while, the language that was available on all sorts of mainframes that addressed business was COBOL. Then one could use FORTRAN for doing engineering & science. All other languages were in the noise, were research projects, or were only supported by a single vendor.
Selecting COBOL made very good sense then and in some cases probably even makes sense now for some classes of applications. Move Corresponding still does a lot of work in a single statement. New editors make working with the verbage easy compared to the venerable 80-column card.
-- Multics
There are two issues here: First, the question of mission critical Microsoft. Second, the question of moving your software.
If I were you, Mr. CIO, I'd avoid this little stunt. Mainframes and the software mainframes run exist in mainframe form for three reasons:
* Speed - Process more data in less time
* Accuracy - With less mistakes
* Reliability - and a minimum of downtime
In none of these areas does Microsoft have a credible track record. You simply have to look elsewhere. Anyone who goes with MS on this is putting their carreer at risk.
That said - would migrating off of Cobol to a more modern development environment make sense? That's a situational question, and one that has to be answered on a case by case basis. In some cases, legacy software is a competitive advantage. In others, it's a business obstacle. In most cases, there's no compelling reason to do or not to do.
-- $G
You are missing his point. He is refering the internal workings not redunacy. The mainframes will double check their working so if errors in the datapath (ie in processor) are picked up and corrected. 80x86 (AFAIK) does not have this kind of checking built into the chip.
http://blog.karit.geek.nz/
"C# applications generally outperform their Java counterparts by a large margin."
.NOT it only works on M$ and Intel CPU's.
.NOT you have your choice of Windoze or Windoze running on intel or amd.
On what?? I find my java programs perform quite well on a 25 cpu *nix box....
Thats the problem with
Right now we are replacing a COBOL app with a cluster of big boxes running Java and Webspere. The nice thing is if we are unhappy with IBM, we could easily move to Sun Sparcs and Weblogic with very little changes to our app. Can't be done with
Alot of big business are very pissed right now with MS over thier licensing and how virus prone thier OS is.
Add to this the fact that most COBOL code is written to a very specific hardware implementation. Most companies will eventully choose to rewrite thier COBOL apps, and given the previous reasons many of them won't even look at MS.
So Long and Thanks for all the Fish.
Yes, clusters can do a job which is "good enough" to replace expensive mainframes, but there are some cases where they aren't good enough, especially banking where you have to be 100% confident that every transaction is logged correctly.
Think about hardware at the gate level, your adders are a bunch of flip flops. A whole lot of them. And very very tiny ones holding very little charge. A cosmic ray striking one can change it's value (I think only form one to zero, or zero to one depending on the process and wether charged or discharged represents a zero or a one). If the cosmic ray hits one of the flip flops that is being used to produce a value about to go to a live register and then off to memory it can change the results from what your code should calulate to something with a one bit error. Maybe a low bit and the result is off by pennies, maybe a high bit and the result is so amazingly off that an assert later in the code catches it, or just a human eyeballing the results would. Worse yet something in the mid rage that nobody notices until far too late (if ever).
This is the same thing that ECC in memory helps prevent (ECC can't protect against multiple bit failures, but while a box with multiple gigs of memory will likely get a soft memory error in your lifetime, multiple bit errors before the scrubber finds them is really really really amazingly unlikely).
It is a force that gets worse as we go to lower voltage systems (less of a hit needed to flip values), and as we get greater densities (more likelyhood of the cosmic ray hitting something other then dead space -- at least I think so on this one).
It can be combated by having ECC on register and cache values (or even parity as long as the bits are "big enough" that a single cosmic ray hit won't flip multiple bits!), but having similar checks on ALU operations, or just sending the values through identical ALUs that are on diffrent parts of the chip and compairing them after (rerun any cycle where the results differ, either totally in hardware or trapping to the OS to let it restart the instruction after logging the hit). Not rocket science, but it makes for a more costly CPU, and it makes for a slightly slower CPU (in fact much slower when you factor in the extra transistors used for correctness checks that a "normal" CPU would use for cache or some other performance boosting geegaw).
As for documentation I don't recall where I saw studies done, probbaly in one of the ACM or IEEE procedings, but if you don't have access to them comp.risks might turn something up (and a lot of other stuff that might be more worth worring about :-)