When selecting a language to port COBOL programs from what language would you chose and why? I am not looking for the answer "because I am familiar with language X".
I am looking for features in a language that map well to COBOL's design.
Update: The programs would run the gammit to utilities, data processing, screens, etc.
Well, you should consider what inputs COBOL programs usually get.
COBOL was designed to process large amounts of fixed-width formatted text as input, to output in much the same manner. This sounds more like an ETL process to me than anything else.
So i wouldn't port COBOL programs to simply another language; I'd port it to suitable ETL technologies such as SQL Server Integration Services (SSIS) or at least its predeccesor DTS - SQL Data Transformation Services. SSIS implies using VB.NET (at least in SQL Server 2005), but that shouldn't be a problem.
I'd personally perform this decision based upon the program's intended design, rather than its current implementation. If you want a straight-out line-for-line port, though, I'd probably say c/c++.
I would port them to ... um ... COBOL. Yes, that's it. COBOL.
Sorry, couldn't resist.
Seriously, there are COBOL compilers for current platforms out there and, unless we know a little more about why the code has to be ported, we may not be able to help.
Is the platform on which it runs obsolete? Is management just pushing for a more 'modern' solution? Are you having to move stiff from System z to Windows (ugh!)?
COBOL (in its purest form, not that OOCOBOL rubbish) is mostly a simple procedural language (ReportWriter notwithstanding) so will translate to any of the other procedural languges fairly well:
Perhaps instead of immediately looking at a new language you could consider transitioning some of your code to a contemporary framework like .Net - you might find that a good intermediatery solution, until you're ready to go the whole hog.
There are a few Cobol compilers for .NET available such as Fujitsu's NetCOBOL.
I once was involved porting some COBOL stuff to C (1989 or so.) The COBOL in question was code to monitor burglar alarms, fire alarms, etc. It was the kind of program that is suited to a more real-time kind of environment. Poll these gazillion customer field devices so many times per minute, etc. Looking "for features in a language that map well to COBOL's design" ignores the fact that there are a lot of COBOL programs out there that ignore COBOL's design.
I don't know much COBOL, but I don't think there is a current language which is a straight superset of it (so, it's not easy to directly map COBOL to the language). I see several problems:
Built-in support for decimal arithmetic - this rules out any modern language without operator overloading.
Better support for structured records - one could use struct/union combo as in C, but I think it would make identifiers very long sometimes (at least for programs I have seen).
Goto statements - without it, one would have to completely analyze the logic of the program when rewriting it.
There may be other features which are not easy to map.
I would keep the COBOL core but expand around the edges.
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
Also, they have a product called COBOL.NET which runs inside Visual Studio and translates COBOL to MSIL. This means that you can then link in any .NET components.
So the approach is to keep the COBOL core but interface via web services and do new developments in any CLR compliant language (C#, VB etc.)