Migrating 3000 sites, as well as prospects, can expect one element to remain the same: COBOL. Unless a company is buying an off-the-shelf application to replace their 3000 suite, COBOL will remain in control even on a platform as novel as Linux. We haven't heard many reports of 3000 sites rewriting from COBOL to anything else, simply to maintain their mission-critical in-house apps. (Ruby, an object oriented programming language, has been stepping in for COBOL at QSS, the K-12 application provider with 3000 customers.) What tips the scales in favor of sticking with COBOL is more than a developer's comfort with the language. Relaxed formatting and structure are hallmarks of any modern COBOL.
Is sticking with COBOL in 2013 a sound choice? To be sure, many 3000 users wouldn't choose COBOL for a brand-new app. Many are developing in other environments (Visual Studio) on what we call surround platforms. The key data remains on a 3000 for now, feeding those other-apps.
But COBOL has changed a great deal, and for the better, if you decide to move away from HP's COBOL II. The language once had a reputation of being verbose. Okay, that hasn't changed. But COBOL in updated flavors has dropped all the fixed A/B margin formatting, uppercase-only text and rigid division-section structure that was still in place when HP left the languages business.
COBOL supporters in your community still like to talk about how readable and maintainable COBOL still is, even in the face of the brace-and-bracket languages world. George Willis of investment house Fayez Sarofim migrated the MPE applications using AMXW, "so that we could 'lift and shift' our COBOL and Powerhouse code with somewhat minimal changes." The company chose HP's Unix as its platform last year, but AMXW works with Windows and Linux, too.
The exception to COBOL is FORTRAN in the 3000 world. MANMAN relies upon FORTRAN for its MRP work, and many a manufacturing site has coded in customizations using FORTRAN. But outside of the manufacturing base, COBOL rules the past as well as the future.
The advantage to starting with a clean slate for a mission-critical application: you choose whatever language fits best. But 3000 sites don't get a clean-slate restart, since the data is always of legacy vintage. You wouldn't write a mobile application in COBOL. But when you consider the tasks 3000 apps perform -- rely on transactions, used record-structured data, handle heavy loads -- COBOL still fits well.
A white paper from Creative Intellect Consulting says that "COBOL's past shortcomings don't compromise its appropriateness for the future." That is only true, however, if a modern COBOL is waiting on the other side of a migration. Everything is more modern than COBOL II, and right at the end of HP's 3000 futures one company modernized COBOL II. The suite that emerged was called AcuCOBOL-GT.
Acucorp released the product as a revamp of MPE/iX COBOL, but it emerged within a few months of HP's 2001 exit announcement. Now AcuCOBOL-GT has been absorbed by Micro Focus, whose Visual COBOL 2.1 is still adding more compatibility for AcuCOBOL. Some companies that made the jump to things like AMXW embraced AcuCOBOL as part of their move.
There are still macro issues to resolve, for the companies which employed them in their 3000 applications. Consultant Michael Anderson of J3k Solutions reports that the way he handled macros in COBOL II while moving to HP-UX is "to compile the original source on MPE, and then use the listfile as the new source code for HP-UX-based AcuCOBOL or Micro Focus COBOL. Then do some cutting and pasting into new copy books (COPYLIBs) on the HP-UX server."
Visual Studio, probably the most widely adopted development environment for companies that rewrote code to .NET, is supported by the Micro Focus product. That support lets customers edit, compile and debug using Visual Studio 2012 or 2010. This COBOL support isn't widely known, if you're examining Visual Studio from the world of Windows. Support for Visual Basic, Visual C#, Visual C++ is built in to the free "Express" versions of Visual Studio. But if your frame of reference for development is COBOL rather than Windows, you'll know that going Visual doesn't mean leaving COBOL behind.
MicroFocus doesn't own all of the modern COBOL choices. There's COBOL-IT, a commercialization of the OpenCOBOL open source code. COBOL-IT has been built by former Acucorp managers, using the same model that's worked in other open source advances: improve upon features without erasing compatibility, then add professional-level support. As recently as two years ago, Speedware (now Fresche Legacy) was promoting the use of COBOL-IT in migrated environments. Fresche is now working closely with Micro Focus, too.
There's also Fujitsu's NetCOBOL, which includes support for .NET as well as Windows' Visual tools. There's a difference in pricing as well as reach between Fujitsu and Micro Focus. NetCOBOL supports Linux and Solaris along with Windows, and it doesn't use a runtime pricing model. The Micro Focus tools -- and there are a mighty raft of them, considering the company aquired Borland, too -- run everywhere. (Well, maybe not under MPE. But there's that Acucorp heritage inside the software, after all.)
Proven success keeps COBOL running much of the world's business computing, more than 50 years after the language was invented. It's hard to refuse something that's worked for this long -- if its community keeps reinventing it. If your IT efforts include care for languages and programs, like so many do, then caring about your next COBOL should be an issue to investigate.