Forgot your password?
typodupeerror
Microsoft Businesses

Microsoft Makes Push for COBOL Migration 487

Posted by Cliff
from the trusting-your-legacy-code-to-.NET dept.
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."
This discussion has been archived. No new comments can be posted.

Microsoft Makes Push for COBOL Migration

Comments Filter:
  • Bah humbug... (Score:5, Insightful)

    by tehdely (690619) * <str8@chir.pn> on Sunday November 09, 2003 @07:15PM (#7430576) Journal
    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... (Score:5, Interesting)

      by Anonymous Coward on Sunday November 09, 2003 @07:28PM (#7430641)
      I work for an insurance company, running a policy administration application running under Windows. We currently administer approximately 150,000 policies, and were recently acquired by another company. They're dumping their mainframe based admin system and we're taking on their policies as well. This system is written in COBOL, and at one time we were using Microfocus COBOL. The vendor switched to Fujitsu COBOL and the next version will be Fujitsu COBOL.net.

      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.
      • Re:Bah humbug... (Score:3, Insightful)

        by 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... (Score:5, Interesting)

      by darnok (650458) on Sunday November 09, 2003 @07:38PM (#7430683)
      > Aren't most COBOL applications deployed on big
      > 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 ... It's very rare to find someone writing COBOL code from scratch; it's all based on changing proven existing code and thus carries a relatively tiny risk of problems occurring after deployment. Furthermore, it's quite common to take the output of one piece of COBOL code, and use that as the input for your new set of COBOL code. Add a few generations of this, and suddenly you're dealing with an enormous mass of COBOL code, possibly largely undocumented and written by guys who retired years ago, that you have to port across to get a single piece of functionality working. It's very difficult to even write test cases for this legacy code, since its original purpose may be totally forgotten and the only reason it still exists is to support all the newer code that's been layered on top of it. This is a big factor that tends to be conveniently forgotten by those who think a move off the mainframe to Windows or Unix is simply a matter of time. A change to the .NET platform, or any other platform for that matter, is simply not feasible for the vast majority of mainframe shops on this basis alone.
      - 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, .NET is often seen as a high risk option. Remember, CICS and MVS have been around for decades, and they're known to work close enough to perfectly. For the type of work COBOL is currently being used for, reliability is absolutely top priority; you don't want your huge transaction processing system to go off the air for even a few seconds while your Windows systems take an outage for patches to be applied.

      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.
      • by kraksmoka (561333) <grant AT grantstern DOT com> on Sunday November 09, 2003 @07:50PM (#7430742) Homepage Journal
        COBOL on big iron will never die. that's for the same reason one of my clients' elevator system is powered by a 100 year old solid state system. he walked me upstairs to show it off. lots of zapping and clicking noises. the thing runs 15 stories worth of 2 elevators and has for 40 years in that building (yes, bought used).

        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!

        • by Anonymous Coward
          Actually an enormous amount of mainframe code was migrated/replaced for Y2K to Unix and 'standard' ERP systems. The reason you didn't hear about it was that a successful migration would have had to start at least 3-4 years eariler. A good chunk of that last minute Y2K COBOL stuff was the result of failed migration/replacement plans.
        • by azzy (86427) on Sunday November 09, 2003 @08:12PM (#7430833) Journal
          If it keeps you in a job, don't fix it completely.
        • COBOL on big iron will never die. that's for the same reason one of my clients' elevator system is powered by a 100 year old solid state system. he walked me upstairs to show it off. lots of zapping and clicking noises. the thing runs 15 stories worth of 2 elevators and has for 40 years in that building (yes, bought used).that reason is reliability. if it ain't broke, don't fix it.

          First off, "solid state" means "no moving/mechanical switching", which a room full of relays does not fit the definition of.

      • Re:Bah humbug... (Score:5, Insightful)

        by ericman31 (596268) on Sunday November 09, 2003 @07:59PM (#7430778) Journal

        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... (Score:3, Insightful)

        by cotopaxi (79618)
        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 Microfo
    • " Aren't most COBOL applications deployed on big iron?"

      Yes, but it's old big Iron. So in many , if not most cases, that mainframe can be replaced by a small server or even a desktop.
      • Re:Bah humbug... (Score:3, Insightful)

        by nzkoz (139612)
        ..... Right. You're clearly someone who has never dealt with a mainframe. You could migrate those systems to a small unix server. Unfortunately, IO throughput will destroy your performance and your nightly batches will take 2 days to run.
        • Re:Bah humbug... (Score:3, Insightful)

          by dperkins (63220)
          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 wh

    • Re:Bah humbug... (Score:3, Insightful)

      by MeanMF (631837) *
      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

      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.
    • Re:Bah humbug... (Score:3, Interesting)

      by Zeinfeld (263942)
      I doubt any Microsoft solution could honestly compete with the scalability and reliability of a true mainframe,

      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 inte

  • You have to admit, this is the most innovative thing Microsoft has done. Ever.

    --ken
    • by Jameth (664111) on Sunday November 09, 2003 @07:26PM (#7430632)
      I don't know, that paper clip was pretty damn innovative. I mean, who else would think to make something like that?
    • by ericman31 (596268) on Sunday November 09, 2003 @07:31PM (#7430651) Journal

      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.
      • by molarmass192 (608071) on Sunday November 09, 2003 @08:13PM (#7430839) Homepage Journal
        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.
    • "You have to admit, this is the most innovative thing Microsoft has done. Ever."

      I assume the parent had his tongue firmly in his cheek, but I don't have any mod points for +1 funny.

      This is an initiative from MicroFocus rather than from Microsoft. I'm sure that MS would love to have those big-iron applications ported to their platforms, but it probably isn't going to happen.

      People want to migrate from the language, not from their platforms. C/C++ and Java are good candidates for these applications, par
  • by fredbox (207869) on Sunday November 09, 2003 @07:19PM (#7430591)
    Microsoft Visual COBOL++.NET 2003

    Available 3rd quarter 2005. Look for Visual COBOL# in 2007.
  • manged?? (Score:4, Funny)

    by Anonymous Coward on Sunday November 09, 2003 @07:19PM (#7430594)
    It allows for COBOL code to be integrated and manged with other code in Visual Studio.

    I think the correct spelling is mangled.
  • hog wash (Score:3, Interesting)

    by Anonymous Coward on Sunday November 09, 2003 @07:21PM (#7430600)
    of all the financial companies that I know, none of them have any plan to replace mainframe with windows boxes. First off, the reliability of mainframes is rock solid and the code is old but robust. It's not the most flexible systems, but they provide 99.999% reliability and tremendous scalability. Windows can't scale to those levels worth shit. Maybe in 20 yrs windows will be half way, but it would require a fundamental rewrite of the entire operating system and all of .NET. Some one over at MS is smoking some serious crack. I know from first hand, most of the big financial firms on Wall street are moving to massive clusters of linux, but the plan is a 5-10 yr process. that is such a joke, migrate Cobol to .NET.
  • by Lxy (80823) on Sunday November 09, 2003 @07:21PM (#7430602) Journal
    Isn't that about 20 lines of C++?
  • by beamdriver (554241) <beamdriver@gmail.com> on Sunday November 09, 2003 @07:22PM (#7430605) Homepage
    Has anyone used Tiny Cobol [sourceforge.net] or Open Cobol [open-cobol.org]
    • by twitter (104583) on Sunday November 09, 2003 @11:46PM (#7431876) Homepage Journal
      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.

  • COBOL migration (Score:3, Informative)

    by bersl2 (689221) on Sunday November 09, 2003 @07:23PM (#7430613) Journal
    This makes me wonder, are there any Open Source projects working to provide for this eventual migration?

    Just from browsing freshmeat: OpenCOBOL [freshmeat.net]
  • Oh no! (Score:5, Funny)

    by Danathar (267989) on Sunday November 09, 2003 @07:25PM (#7430625) Journal
    This is just going to result in the resurgance of COBOL! Not the migration away from it! BASIC was literally almost DEAD until microsoft came out with Visual Basic. What do you think this will do for COBOL!

    I DO NOT want to have to debug visual COBOL!
    • by tb3 (313150)
      And I call Visual Basic "The COBOL of the nineties". Produced the same kind of spagetti-code legacy apps that COBOL did.

      And by the way, Visual COBOL is either a MicroFocus or Microsoft product.
  • Why would you? (Score:5, Interesting)

    by msgmonkey (599753) on Sunday November 09, 2003 @07:25PM (#7430626)
    As long as it works and there are no issues like Y2K why would you get rid of something that works? It's not like new machines wont run COBOL programs.
    • Re:Why would you? (Score:5, Interesting)

      by Tablizer (95088) on Sunday November 09, 2003 @07:44PM (#7430716) Homepage Journal
      As long as it works and there are no issues like Y2K why would you get rid of something that works? It's not like new machines wont run COBOL programs.

      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?
  • sourceforge webpage [sourceforge.net]

    Doesn't implement everything. Judging from the state of a university, much of the cobol stuff needs to be replaced, because to get useful things out of it requires all sorts of research, because very very few people know how to write it without breaking systems in use for 20 years or so, that do work.

    Of course, what they are replacing it with often has a worse reputation (in one instance a university is going with peoplesoft, a program dumped by another university in the state because

  • by dillon_rinker (17944) on Sunday November 09, 2003 @07:28PM (#7430640) Homepage
    ...allows for COBOL code to be integrated and manged...

    That's right, folks! .NET for ALL your COBOL needs! Want your COBOL code to be hairless, oozy, and irritated? Then .NET is for YOU!

    • Want your COBOL code to be hairless, oozy, and irritated?

      Hairless, oozy, and irritated? You're talking about Ballmer, right?

      If it's not Consolidated Lint, it's just fuzz!

  • by checkitout (546879) on Sunday November 09, 2003 @07:30PM (#7430649)
    Information week has an article from Nov. 3, 2003 noting that 38% of Gartner's shares are owned by Microsoft, Oracle, Dell and a few other major players. All of whom would presumably benefit from what Gartner has to "report" about their respective fields of interest.

    Considering that Gartner has been charged with bias from some circles already, this can't help things.

    Who Owns Gartner? [informationweek.com]
  • by King_TJ (85913) on Sunday November 09, 2003 @07:31PM (#7430650) Journal
    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.

    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 .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!"
    • I don't think legacy hardware is a problem at all. That market isn't like the PC market where the maker pretends that it didn't exist if it is more than three years old.

      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.
  • by Dinosaur Neil (86204) on Sunday November 09, 2003 @07:31PM (#7430652)

    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.

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

      This is the problem. Why fix it when it already works and the people who understand how to work on it are retiring and dying from old age? And the fact that mainframes are a huge scam? For example, take the Unisys mainframe where I work. We do not own it, we rent it. It sits in a room. We get to use less than half

      • It's not a scam, it's simple economics. It's cheaper for Unisys or IBM to design and ship fewer unique hardware configurations. That's why you get CPUs and other devices that can be upgraded by changing a jumper or loading a new set of microcode. Many calculator manufacturers do something similar. They crank out millions of generic calculator boards. The actual model and feature set is determined by the case and keyboard.
    • Plus nobody seems to consider the premise that mainframe systems perhaps... "aren't dying."

      Everything has its ups and downs like the business cycle. Mainframes were big... then horizontal scaling and PC's... now mainframes are coming back in a big way. With a brand spanking new z series box you can have virtual Linux boxen by the 100's or 1000's... and you get IBM's rock solid reliability. So TCO goes up on price of single box and way way down on prices of MANY pieces of hardware that are replaced over
  • Emulation? (Score:4, Funny)

    by G4from128k (686170) on Sunday November 09, 2003 @07:33PM (#7430663)
    Maybe they are rewriting Virtual PC to run on the IBM 360.
  • Manged (Score:2, Funny)

    by Nemi (627009)
    "It allows for COBOL code to be integrated and manged with other code in Visual Studio"

    From dictionary.reference.com:

    Manged:
    adj. Refers to anything that is mangled or damaged, usually beyond repair.

    Gotta love a binary shreader...

  • by Space cowboy (13680) on Sunday November 09, 2003 @07:35PM (#7430671) Journal
    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.

  • by Anonymous Coward
    Why go with some brand new technology when there is already something solid that works?

    There are a few CORBA-compliant ORBs out there supporting COBOL language bindings.

    Today, without waiting for some new M$ product, you can develop a CORBA layer to sit on top of the COBOL code, and then interface to the existing code from whatever other environment you wish.

    Sooo, to expand the system, you can write your new code in whatever language on whatever OS you choose and still leverage the old system. You can al
  • by cmacb (547347) on Sunday November 09, 2003 @07:40PM (#7430696) Homepage Journal
    I don't know, but something about all of Microsoft's recent announcements make me wonder if I am not having one great big lucid dream experiences.

    I guess it started with the active directory thing that starts to move everything about an individual user back to a central server. Then grabbing the Citrix technology to essentially turn a PC into a dumb terminal. Now all of a sudden they no longer want to hide the Command Line Interface and are coming out with a new one with supposedly decent scripting capabilities. Now this!

    Well, you know you can sort of steer a lucid dream anywhere you want to go, so here is what's coming out soon from Redmond:

    Punch Cards: No more worrying if that last CD backup you did of your system is really readable. Now anything on your system can be easily converted to 80 column Hollerith format. The new WinPunch will attach to a standard USB port and allow for both punching and reading of standard IBM punch cards. Special programs will allow your keyboard to be used to directly punch these cards, or you can program your own virtual IBM 029 drum card to speed up repetitive tasks.

    Paper Tape: For you PDP and other non-IBM users there is WinPT which will have similar I/O capabilities but use either roll based paper tapes or the much preferred fold style. Thanks to new fabrication techniques and years of work by the Microsoft R& D lab much higher densities will be available than those you remember.

    WinHenge: Tired of using those old techniques to figure out when the summer solstice will begin?.....
    • > 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).
  • by Animaether (411575) on Sunday November 09, 2003 @07:49PM (#7430739) Journal
    this seems like a huge potential market to lose to Microsoft


    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.
  • I've noticed /.'ers mentioning two COBOL compilers (OpenCOBOL and TinyCOBOL). It makes me wonder why more mainframe COBOL apps aren't just redeployed on Linux. No rewriting, nothing. How hard could it be to write a COBOL compiler that also inserts code to emulate quirks of the old OS and compiler?

    I'm surprised this doesn't happen more often.

    Indeed, one idea that seems obvious to me is to create a shell and environment that runs under GNU/Linux which looks and acts like the mainframe interface, except t
    • 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.
  • by Anonymous Coward on Sunday November 09, 2003 @07:52PM (#7430753)
    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.
  • by madmarcel (610409) on Sunday November 09, 2003 @07:54PM (#7430757)
    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 :)
  • by smartin (942) on Sunday November 09, 2003 @08:01PM (#7430786)
    It allows for COBOL code to be integrated and manged with other code in Visual Studio.

    Did the author intend to say managed or mangled ?
  • by Garg (35772) on Sunday November 09, 2003 @08:02PM (#7430791) Homepage
    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
    • Exactly, every single UNIX / linux fan who says 'Stuff mainframes, run *nix' has essentially missed the point. Sure you can port the COBOL code over, but without CICS, DB2, VSAM, IMS et. al. your code will be basically worthless.

      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
  • Circle Ten? (Score:4, Funny)

    by sbaker (47485) on Sunday November 09, 2003 @08:13PM (#7430837) Homepage
    Windows, .NET *and* COBOL? Looks like Dante missed a circle.
  • A joke. (Score:5, Funny)

    by Mr_Icon (124425) * on Sunday November 09, 2003 @08:21PM (#7430880) Homepage
    On the eve of the New Year 2000, an old programmer went out of his house to go to a party, but was run over by a bus before he could get there. His vision went dark, but then he saw wonderful white light and people in white clothes leaning over him.
    "Where am I?" he said.
    As soon as he spoke, everyone started cheering and congratulating each-other.
    "What is going on?" he said, amidst the brouhaha.
    "You see, this is many thousands of years after your time," told him one man in a white labcoat. "The medicine has made huge advancements, and now we are able to revive people who have died millenia ago."
    "Wow," said the old programmer, "this is really great. But why me?"
    "Well, you see, this is the year 9999 -- we are facing the Y10K problem, and your resume said that you know COBOL..."
  • by salesgeek (263995) on Sunday November 09, 2003 @08:25PM (#7430907) Homepage
    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.

    • Support (Score:3, Interesting)

      by Detritus (11846)
      I would add longevity of support. Is the company going to support their current hardware and software products in 5 years, 10 years, 20 years? Microsoft, and many other companies, have a bad habit of pushing something for a few years and then ditching it, leaving their customers dangling in the wind. Microsoft has a long list of products and technologies that are no longer supported.
  • by UltraSkuzzi (682384) on Sunday November 09, 2003 @08:31PM (#7430926) Homepage
    000100 IDENTIFICATION DIVISION.
    000200 PROGRAM-ID. COBALISTEHL33T.
    000300
    000400*
    000500 ENVIRONMENT DIVISION.
    000600 CONFIGURATION SECTION.
    000700 SOURCE-COMPUTER. RM-COBOL.
    000800 OBJECT-COMPUTER. RM-COBOL.
    000900
    001000 DATA DIVISION.
    001100 FILE SECTION.
    001200
    100000 PROCEDURE DIVISION.
    100100
    100200 MAIN-LOGIC SECTION.
    100300 BEGIN.
    100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
    100500 DISPLAY "What they think they d0ing?! C0b0l is teh l33t! Someone tell microsoft to go back to the crap 86, we don't need him with our cool VT100 world!"
    LINE 15 POSITION 10.
    100600 STOP RUN.
    100700 MAIN-LOGIC-EXIT.
    100800 EXIT.
  • by iggymanz (596061) on Sunday November 09, 2003 @09:02PM (#7431103)
    just fine. MicroFocus is available on Linux and your Unix of choice (I've actually done healthcare adjudication app porting & integration on Linux, AIX, and HP/UX). It has a C API so you can go back and forth between any langauge that supports that (I did Java via JNI). Fujitsu also makes a kick-butt enterprise grade COBOL compiler for Linux & your Unix of choice, and I'm sure there's plenty others out there.

    That being said, for 1,000's of users, the mainframe is still the cheapest for price/user. In the 10's to 100's of users, Unix or Linux on server grade machine is dandy.
  • by Jamie Zawinski (775) <jwz@jwz.org> on Sunday November 09, 2003 @09:43PM (#7431305) Homepage

    It's called "ADD ONE TO COBOL GIVING COBOL."


    (Yes, this joke is at least 15 years old...)

  • by foistboinder (99286) on Sunday November 09, 2003 @09:45PM (#7431313) Homepage Journal

    The stability of Microsoft combined with the elegance of COBOL.

  • by PinchDuck (199974) on Sunday November 09, 2003 @11:06PM (#7431699)
    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.
  • In My Day... (Score:3, Interesting)

    by tspauld98 (512650) on Sunday November 09, 2003 @11:20PM (#7431773)
    good software engineering meant using the right tool for the right job. Only a web script kiddies with no mainframe exposure or experience would think this story is newsworthy. Every company or organization that I've had experience with and that has a mainframe always laughs at the idea that they would migrate anything off host. Just because Big Blue originally hired MS to do software has always translated to MS that they can play in this market. I like to quote Charlton Heston whenever somebody suggests that they are going to take my mainframe away, "from my cold, dead hands!!!"

    oh, and btw, I'm not a COBOL programmer. just someone who respects them enormously. Props to the host team!

    tims
  • by Lawrence_Bird (67278) on Monday November 10, 2003 @01:17AM (#7432229) Homepage
    by 5B lines per year, which is quite impressive.


    You could have known this 5 days go though... # 2003-11-04 15:43:28 Microsloth courts COBOL (articles,microsoft) (rejected)
  • Solution: (Score:3, Interesting)

    by master_p (608214) on Monday November 10, 2003 @07:48AM (#7433092)
    A Cobol-to-C++ translator.

    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.
  • Grrrrr! (Score:3, Insightful)

    by nurb432 (527695) on Monday November 10, 2003 @09:28AM (#7433431) Homepage Journal
    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
  • by DukeyToo (681226) on Monday November 10, 2003 @10:25AM (#7433725) Homepage
    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.
  • They can keep it (Score:3, Interesting)

    by carldot67 (678632) on Monday November 10, 2003 @05:27PM (#7437412)
    Confession: Many years ago I was a COBOL programmer at several big mainframe shops.

    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.

Chemist who falls in acid is absorbed in work.

Working...