Converting COBOL code to C# ?

[dm1608]

We have a number of COBOL programs, and some were currently developing, that
simply read TEXT based reports and scrap the reports for various
information.

I'm curious to know if anyone has attempted to do this sort of thing using
C#?

I would love to get rid of my COBOL programmer and especially the code, if I
can. Apparently, it is much simplier to edit/parse text reports in COBOL
than other languages.... so I'm being told.


Any samples or online references would be great.

Please note that some reports are multi-page and some may have special
"binary" coded headers that is used for printers, etc., that are typically
ignored by the parser.

 

[Guest]

I don't know anything about COBOL, so I can't compare the two. But in .NET,
it is fairly straight forward reading and writing files.

Take a look at the System.IO namespace. There are classes in there for
reading files as binary files, text files, file streams, memory streams, etc.


Look at the System.Text namespace for classes for different character
encodings. The System.String class has may methods for common string parsing.

http://msdn.microsoft.com/library/d...us/cpref/html/frlrfsystemstringclasstopic.asp

I have no clue about COBOL, but it's real easy in .NET (C# or VB.NET).

 

[Guest]

dm1608,

I am reasonably sure that at least one vendor (Fujitsu, I believe) has a
COBOL.NET language product. You can use the existing COBOL codebase to create
..NET assemblies, and then simply decompile them into C# using a free product
such as Roeder's Reflector.
Peter

 

[Ian Semmel]

I think that if he goes to the trouble of buying a COBOL compiler, he may as
well leave the programs in COBOL (and save his poor programmer's job!).

I have written hundreds of COBOL programs (although not for many years) and it
is good for the applications he describes.

My experience in converting systems is that it is better to recode into the new
language rather than relying on some automatic translation system. You have the
best spec in the world - an existing working system - to verify your results.

Perhaps recoding to VB would be easier ?

 

[Bruce Wood]

Apparently, it is much simplier to edit/parse text reports in COBOL than other languages.... so I'm being told.

We program in both COBOL and C#. I also have close to 20 years'
experience using C, with some Java and C++ mixed in there.

What COBOL is really good at, parsing-wise, is reading fixed-position
records. That is to say if your report always has the print date at the
56th character position of the 3rd line then getting at it using COBOL
is a breeze.

However, getting at it with C# isn't very difficult, either. It may not
be as elegant as the COBOL program, but then it's not going to be an
ugly mess, either. A bit more complex, but not much.

Where COBOL really falls down is in any of the following situations:

1. Reports with lines of varying lengths, where you may not know the
maximum.
2. Cases in which you want to organize and summarize the report
information before writing it out. C# has far richer data structures
for collecting and reorganizing information (although COBOL is no
slouch).

and the biggie

3. Reports that have information that can move about on a line or on
the page, for which you have to search using some sort of pattern. C#
has Regular Expressions. COBOL has... well, not much.

All in all, if the COBOL is costing you a lot of money, and switching
to another language (like C#) would save you money, I don't see COBOL
being so much better at the job that it would pay for itself.

If you have C# (or VB.NET) programmers on staff, give them a report to
parse and see how it goes. That will tell you a lot.

As for COBOL.NET compilers, yes, Fujitsu makes one. So does MicroFocus.

http://www.netcobol.com/

http://www.microfocus.com/index.asp?bhcp=1

 

[Guest]

dm1608,

I am reasonably sure that at least one vendor (Fujitsu, I believe) has a
COBOL.NET language product. You can use the existing COBOL codebase to create
.NET assemblies, and then simply decompile them into C# using a free product
such as Roeder's Reflector.

I'll admit to displaying my ignorance of COBOL here, but I thought it was a
non OO langauge. With .net being completely OO, I'm wondering how the
compiler would be able to convert the COBOL code into, IL at all, never mind
something non nightmarish when reflected back into C#.

 

[Joerg Jooss]

Thus wrote Dan,

I'll admit to displaying my ignorance of COBOL here, but I thought it
was a non OO langauge. With .net being completely OO, I'm wondering
how the compiler would be able to convert the COBOL code into, IL at
all, never mind something non nightmarish when reflected back into C#.

Yes, there is OO COBOL.
No, it's still not pretty. Just like its ancestor.

Cheers,

 

[William Stacey [MVP]]

c# is pretty darn flexible for parsing just about anything. If you could
export the reports into xml, then parsing becomes almost a non-issue for
..Net languages. If not, you can manually parse, use regex, string.split.
Post a simple sample report and am sure you will see many c# ways to do it.

--
William Stacey [MVP]

| We have a number of COBOL programs, and some were currently developing,
that
| simply read TEXT based reports and scrap the reports for various
| information.
|
| I'm curious to know if anyone has attempted to do this sort of thing using
| C#?
|
| I would love to get rid of my COBOL programmer and especially the code, if
I
| can. Apparently, it is much simplier to edit/parse text reports in COBOL
| than other languages.... so I'm being told.
|
|
| Any samples or online references would be great.
|
| Please note that some reports are multi-page and some may have special
| "binary" coded headers that is used for printers, etc., that are typically
| ignored by the parser.
|
|
|

 

[Willy Denoyette [MVP]]

|
|
| "Peter Bromberg [C# MVP]" wrote:
|
| > dm1608,
| >
| > I am reasonably sure that at least one vendor (Fujitsu, I believe) has a
| > COBOL.NET language product. You can use the existing COBOL codebase to
create
| > .NET assemblies, and then simply decompile them into C# using a free
product
| > such as Roeder's Reflector.
|
| I'll admit to displaying my ignorance of COBOL here, but I thought it was
a
| non OO langauge. With .net being completely OO, I'm wondering how the
| compiler would be able to convert the COBOL code into, IL at all, never
mind
| something non nightmarish when reflected back into C#.

COBOL is not the COBOL it was 20 years ago. Microfocus an Fujitsu have both
a version that compiles to MSIL and supports the OO paradigm. As a business
oriented application builder it has some language features not available in
C# (which is a general purpose language) and the Framework.
Ever tried to write some CICS transactions using C#? A few hundred lines of
MF Cobol code is all you need to build a 3270 CICS front-end. Note also that
it perfectly integrates into .NET so it can access all framework features
available to the other .NET languages (think DB connections through ADO.NET,
remoting, enterprise services, XML etc....)
Really a nice product, gaining some popularity in large businesses
(especially main-frame scenarios), but quite expensive.


Willy.

 

[dm1608]

We use MicroFocus COBOL for .NET 2003. One of the other main issues I have
with MicroFocus is that they require me to have a licensing server on the
network. If I write a MicroFocus COBOL program on my development machine,
it will run fine. As soon as I give my EXE to someone else to run... it
will fail because I have to have a license server somewhere on the network.
Very lame.

It's also very costly.

I can write many of the same apps in .NET VB or C# and not have to worry
about a stupid licensing dependencies.

Opinions?

 

[AAJ]

I can't help with an answer, but all the programmers in our office agree its
one of the best posts we have ever read - we all feel very nervous !!!

 

[Guest]

|
|
| "Peter Bromberg [C# MVP]" wrote:
|
| > dm1608,
| >
| > I am reasonably sure that at least one vendor (Fujitsu, I believe) has a
| > COBOL.NET language product. You can use the existing COBOL codebase to
create
| > .NET assemblies, and then simply decompile them into C# using a free
product
| > such as Roeder's Reflector.
|
| I'll admit to displaying my ignorance of COBOL here, but I thought it was
a
| non OO langauge. With .net being completely OO, I'm wondering how the
| compiler would be able to convert the COBOL code into, IL at all, never
mind
| something non nightmarish when reflected back into C#.

COBOL is not the COBOL it was 20 years ago. Microfocus an Fujitsu have both
a version that compiles to MSIL and supports the OO paradigm.

So the new compilers can only convert Object Cobol into MSIL, and not nonOO
legacy code?

Ever tried to write some CICS transactions using C#? A few hundred lines of
MF Cobol code is all you need to build a 3270 CICS front-end.

I've never had to do anything mainframe related, and never heard of cics
before today.

 

[Willy Denoyette [MVP]]

|
|
| "Willy Denoyette [MVP]" wrote:
|
| >
| > | > |
| > |
| > | "Peter Bromberg [C# MVP]" wrote:
| > |
| > | > dm1608,
| > | >
| > | > I am reasonably sure that at least one vendor (Fujitsu, I believe)
has a
| > | > COBOL.NET language product. You can use the existing COBOL codebase
to
| > create
| > | > .NET assemblies, and then simply decompile them into C# using a free
| > product
| > | > such as Roeder's Reflector.
| > |
| > | I'll admit to displaying my ignorance of COBOL here, but I thought it
was
| > a
| > | non OO langauge. With .net being completely OO, I'm wondering how the
| > | compiler would be able to convert the COBOL code into, IL at all,
never
| > mind
| > | something non nightmarish when reflected back into C#.
| >
| > COBOL is not the COBOL it was 20 years ago. Microfocus an Fujitsu have
both
| > a version that compiles to MSIL and supports the OO paradigm.
|
| So the new compilers can only convert Object Cobol into MSIL, and not
nonOO
| legacy code?
|
|

No at all, the .NET Cobol compiler can emit CIL to run under the CLR or
just native code and integrates with VS.

| > Ever tried to write some CICS transactions using C#? A few hundred lines
of
| > MF Cobol code is all you need to build a 3270 CICS front-end.
|
| I've never had to do anything mainframe related, and never heard of cics
| before today.

I see, but there other features included, for instance you can expose COBOL
objects (CLR objects) as JavaBeans, COBOL can call Java objects and Java can
call COBOL objects through their built-in J2EE connector.

Willy.

 

[Joerg Jooss]

Thus wrote dm1608,

We use MicroFocus COBOL for .NET 2003. One of the other main issues
I have with MicroFocus is that they require me to have a licensing
server on the network. If I write a MicroFocus COBOL program on my
development machine, it will run fine. As soon as I give my EXE to
someone else to run... it will fail because I have to have a license
server somewhere on the network. Very lame.

It's also very costly.

I can write many of the same apps in .NET VB or C# and not have to
worry about a stupid licensing dependencies.

Opinions?

I thought they'd got rid of that with their latest version of NetExpress
and ServerExpress... ouch!

 

[dm1608]

Yeah--I basically told their sales person that I'd rewrite any new apps
using less expensive solutions going forward because they just priced
themselves out of the market. If every application created its own
licensing server... I think I would have to find a new field.

 

[Bruce Wood]

I believe that the licensing is for the COBOL runtime: all of that
extra "COBOL" stuff without which a COBOL program can't survive.

My impression is that their target for this whole rig-up is "big iron"
shops that want to get their COBOL programs off of their big machines
and onto smaller servers, with the added bonus of being able to port
them to .NET and maybe slap a WinForms front end on them.

I'm heading down to the MicroFocus conference ten days, but my
impression from a couple of years ago is that they have no illusions
that they're going to get a lot of new business jumping on board making
COBOL their "language of choice" for development. As Joerg points out,
it's not a pretty language, and the O-O version is even worse. If I
were writing a program to distribute to all and sundry, I wouldn't be
doing it in COBOL. In fact, in our shop, all client-side development is
in C# or Access (ugh). We couldn't care less about COBOL.NET.

So, I think that MicroFocus is targeting the legacy "big iron" market,
where paying for a license server is no big deal, and IMHO it's a smart
move on their part.