4

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.

ojblass
  • 21,146
  • 22
  • 83
  • 132
  • It really depends on where you're porting TO and why. If you're going from an IBM mainframe to a DEC/Compaq/HP Alpha, you'd probably want to stick with COBOL :) – David May 29 '09 at 14:13

9 Answers9

8

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 stuff from System z to Windows (ugh!)?

COBOL (in its purest form, not that OO-COBOL rubbish) is mostly a simple procedural language (ReportWriter notwithstanding) so will translate to any of the other procedural languges fairly well:

  • C.
  • C++ without classes
  • Java, although you can't avoid classes unless you have one big honkin' singleton.
  • Pascal (swapping one 'dead' language for another).
  • even Python, Perl et al can be made to work.
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • screens screams ncurses to me but that might be just because I am not familiar with other languages... – ojblass Apr 21 '09 at 05:42
  • I can see using c/java/pascal....but Python, perl, et al lack any sort of support for fixed point decimal. Without fixed point decimal support, you just can't do large financial stuff with accuracy. – Joe Zitzelberger Jan 12 '11 at 14:18
4

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.

Jon Limjap
  • 94,284
  • 15
  • 101
  • 152
  • Funny this was downvoted. I was only answering this in context of my own experience using COBOL in a big bank. – Jon Limjap Apr 21 '09 at 07:04
3

First one has to as why COBOL has to be ported? COBOL is a powerful time honored language which most likely still has more lines of code running payroll, accounting, etc. in production than any other language.

The least painful port would be Synergy DBL. This is a highly portable VM style update of DIBOL (Digital Business Oriented Language).

http://www.synergex.com/synergy-dbl/

DIBOL used all of the good pieces from BASIC, FORTRAN and COBOL leaving out most of the bad.

If you following the above link you will see they have GUI, .NET and other enhancement tools. Just be certain there is a VM for whatever target OS you will be running on.

IBM Mainframe COBOL making heavy use of CICS, TCAM, IDMS, etc. will be a really tough port to anything else.

OpenVMS COBOL making use of DECForms or possibly even FMS will be a tough port without a screen handling package. Very old COBOL from those shops will make copious use of system services and run time library routines provided by the OS which won't be available on most other platforms. You will also have to read up on logicals and figure out how to implement something kinda-sorta-close-enough on your target.

What you will find with most mainframe and mid-range COBOL is that you are not porting just COBOL. There will be tons of system services which older COBOL made use of.

user3450148
  • 851
  • 5
  • 13
2
  • I have to say you shouldn't port COBOL.
    • If you mean rewrite, then yes, choose a language. I would suggest a web interface, java or .Net, to rewrite in.
    • If the code needs to run exactly like it runs now, any "porting" conversion will only do harm.
  • If you must change platforms for some reason, you can use COBOL on another platform.
  • What has worked best in my experience is to try separating components or services from each other, and either converting small pieces individually or just writing new code in a preferred language, keeping the COBOL running in the back-end.
Abacus
  • 2,041
  • 1
  • 18
  • 23
2

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:

  1. Built-in support for decimal arithmetic - this rules out any modern language without operator overloading.

  2. 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).

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

J S
  • 1,105
  • 7
  • 11
1

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

1

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.

Bayard Randel
  • 9,930
  • 3
  • 42
  • 46
1

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.

smcameron
  • 2,547
  • 1
  • 19
  • 12
1

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

rbrayb
  • 46,440
  • 34
  • 114
  • 174
  • Is this full COBOL and not some barstardized version that sort of looks like the standard but is not aka ie and it's standards implementation. – mP. Apr 22 '09 at 06:06
  • Yup - full standards support. – rbrayb Apr 22 '09 at 19:10