Cobol - cobol to dotnet

Author

cobol to dotnet

Teo

2007-07-05, 6:55 pm

Is possibile the "porting" of cobol programs into .net??

Thx
Teo

cblkid@yahoo.com

2007-07-05, 6:55 pm

On Jul 5, 1:17 pm, "Teo" <teo @ bipp> wrote:
> Is possibile the "porting" of cobol programs into .net??
>
> Thx
> Teo

Yes it is very possible...within certain limits. Can you tell us what
the current platform the COBOL code is running on? Is it a mainframe?
Does it have an OLTP such as CICS or IMS? What is the datastore (DB2,
IMS, VSAM)? Does it have any assembler?

If you can tell us more about the current environment I'm sure we can
assist.

William M. Klein

2007-07-05, 6:55 pm

Both Micro Focus and Fujitsu sell COBOL compilers specifically targeted at .NET.
Depending on what compiler (and platform) you currently are on, this will be an
easy or hard migration. Neither of this compilers are cheap.

--
Bill Klein
wmklein <at> ix.netcom.com
"Teo" <teo @ bipp> wrote in message
news:468d35aa$0$37193$4fafbaef@reader3.news.tin.it...
> Is possibile the "porting" of cobol programs into .net??
>
> Thx
> Teo
>
>

Pete Dashwood

2007-07-06, 3:55 am

"Teo" <teo @ bipp> wrote in message
news:468d35aa$0$37193$4fafbaef@reader3.news.tin.it...
> Is possibile the "porting" of cobol programs into .net??
>
> Thx
> Teo
>
>

Absolutely! I'm doing it all the time. Have a look at InteropServices. Wrap
your COBOL object as a COM component and away you go...

In fact, this is not a great long term solution because your COBOL has to
run as unmanaged code in the DotNET environment, but it buys you the time
you need to look at converting the COBOL and upgrading the functionality
into the DotNET environment.

If you want more details you'd need to specify what COBOL you are using...

Pete.

Pete Dashwood

2007-07-06, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:aGdji.75516$Xu1.18263@fe07.news.easynews.com...
> Both Micro Focus and Fujitsu sell COBOL compilers specifically targeted at
> .NET. Depending on what compiler (and platform) you currently are on, this
> will be an easy or hard migration. Neither of this compilers are cheap.
>

With retrospect, and having had nearly six months experience now at moving
stuff into DotNET, I can't see why anyone would buy the .NET COBOL
compilers.

They are both excellent products and my first impulse was to buy one of them
(Fujitsu) and simply re-compile everything to CLR. Unfortunately, that
didn't work out and I was so disillusioned and angered by the lack of
response from Fujitsu that I decided to look for an alternative approach.

Now, I can see that being forced to go another way was actually a blessing
in disguise. It forced me to come to grips with what is actually going on in
the world outside of COBOL.

Like it or not, OO has inherited the Earth. The non-procedural paradigm is
the status quo for everyone outside of COBOL. There are very valid reasons
why the procedural paradigm has a limited lifetime but I won't digress into
them here.

The point is that anyone who has enough nouse to see that DotNET/Mono is
where they need to go, should also realise that COBOL is NOT the vehicle to
get there.

It's a bit like seeing the Promised Land, going there, but refusing to speak
the local language when you get there. Then wondering why you are missing
many of the benefits because the natives don't understand the Latin you are
speaking. OO COBOL is like pidgin Latin in this scenario; it allows you to
get by, and is certainly better than insisting on pure Latin, but it still
doesn't help you integrate comfortably into the new environment.

Sooner or later you are going to have to learn the local lingo, if you want
to have the full benefits of being there.

So, what are your options?

1. Learn the lingo before you go.
2. Learn pidgin to help ease your transition.
3. Live in a ghetto that speaks Latin.

Option 1 sounds good, and most of us buy a phrase book at least before
travelling to foreign shores.

Unfortunately, we have many reference volumes we need every day and these
are still in Latin. It would be a huge task to translate them all into
NewSpeak, so our new friends could share them.

Fortunately, there are some parts of these references that are used much
more frequently than other parts. If we can provide a "wrapping" in pidgin
for these parts, everybody can share OK. But that means Option 2. And we are
still forced to maintain these pages in Latin. Our children are not going to
learn Latin, so when Grandpa dies, this maintenance will not be possible.

Failure to do either of the two options above, results in Option 3.

Some people are happy with that, but the rising generation want to live life
to the full. They will go to a school where NewSpeak is the language. They
will be involved in all of the activities which make the Promised Land
the....Promised Land.

I would strongly recommend people to start thinking about moving off COBOL,
now. Eventually, you will have no choice. The sooner you start, the easier
the transition will be.

For mainframes the transition will be through Java (if you haven't learned
it yet, get started). Find out about WebSphere and Web Services. Think about
re-factoring COBOL functionality into shared Web Services.

For Client/server it can be Java, C++, or C#.

For myself, I have found C# to be excellent. The DotNET framework lets me
run my essential services (written in OO COBOL) as "unmanaged code" (it
takes no responsibility for it, but runs it as is...provided these services
are bug free, you will have no trouble; if they start breaking bounds or
causing unhandled exceptions, DotNET will drop them like a hot
potato...Fortunately, the debugging facilities are excellent, so it is
relatively easy to find problems.)

Finally, (on topic precisely) moving your existing COBOL to DotNET does NOT
mean you HAVE to buy a DotNET COBOL compiler. All this does is cost you
money and perpetuate a dying paradigm. Bite the bullet and see this
transition as a chance to move into the 21st century. Refactor and wrap your
existing COBOL to run under DotNET using a DotNET compatible language (C# is
free and worth many times the price... :-))

Pete.

Judson McClendon

2007-07-09, 9:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
>
> With retrospect, and having had nearly six months experience now at moving
> stuff into DotNET, I can't see why anyone would buy the .NET COBOL
> compilers. ...
>
> Now, I can see that being forced to go another way was actually a blessing
> in disguise. It forced me to come to grips with what is actually going on
> in the world outside of COBOL.
>
> Like it or not, OO has inherited the Earth. The non-procedural paradigm is
> the status quo for everyone outside of COBOL. ...

I agree completely with that much of Pete's comments. I believe one of the
reasons COBOL was so successful is the power and flexibility of the Data
Division. But .NET views data in a *vastly* different way than traditional
COBOL. And if you're giving up the power of the Data Division, what's the
point of COBOL? It's no longer COBOL. Though I have written millions of
lines of COBOL, and loved the language as much as anyone, I have to admit
that the Procedure Division can be a bit clunky, when compared with some
other languages. Without the traditional Data Division, I don't see any
compelling reason to use COBOL in the .NET environment.

If you spend much time with .NET, it becomes clear that the .NET developers
wanted to reduce the importance language choice. In .NET, 'OO' doesn't
merely mean 'Object Oriented', it means 'Object Obsessed'. Even atomic data
types like integers and strings are objects, with properties and methods,
which do most of the work in string handling. For example, the string
handling capabilities of VB 2005 is emasculated, in comparison to any
version of BASIC seen in the last 30 years. BASIC has long been known for
its powerful string handling features, yet there are almost none in the VB
2005 language itself. String concatenation '+' and '&' are the only ones
that come immediately to mind (i.e. making VB 'string stupid' like C).
However, the VB language still supports lots of arithmetic and logical
operators for numeric data types. In fact they've added C's +=, *=, etc.
arithmetic assignment operators (i.e. making VB 'number smart' like C). The
effect of all this is to make your .NET language choice simply a matter of
which syntax you prefer, not for any power inherent in the language itself,
because those variations the .NET developers have taken care to eliminate.
This applies also to any .NET COBOL. So, as much as I have enjoyed
programming in COBOL since 1968, I do not prefer to code "PERFORM
VARYING FROM BY UNTIL END-PERFORM" over "For Next" or
"Do While Loop" or "do () {};" if I'm going to have to use .NET to
define and massage data anyway.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Howard Brazee

2007-07-10, 6:55 pm

On Mon, 9 Jul 2007 17:29:49 -0500, "Judson McClendon"
<judmc@sunvaley0.com> wrote:

>I agree completely with that much of Pete's comments. I believe one of the
>reasons COBOL was so successful is the power and flexibility of the Data
>Division. But .NET views data in a *vastly* different way than traditional
>COBOL. And if you're giving up the power of the Data Division, what's the
>point of COBOL? It's no longer COBOL. Though I have written millions of
>lines of COBOL, and loved the language as much as anyone, I have to admit
>that the Procedure Division can be a bit clunky, when compared with some
>other languages. Without the traditional Data Division, I don't see any
>compelling reason to use COBOL in the .NET environment.

Also, there is a distinct advantage in having all of our code in one
program - we don't have confusion between running things from
different libraries (I hate debugging tools such as JBuilder settings
instead of Java).

But once we realize that this doesn't fit our new environment, it's
easier to have real small components. I want to look at a "program"
that is small and concise. CoBOL isn't small and concise. If you
want a big program that is clear, CoBOL excels, but small components
can be clear much more easily.

Pete Dashwood

2007-07-10, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:c657935l12ni5kh5mqrlg59imn7sd32p0k@
4ax.com...
> On Mon, 9 Jul 2007 17:29:49 -0500, "Judson McClendon"
> <judmc@sunvaley0.com> wrote:
>
>
> Also, there is a distinct advantage in having all of our code in one
> program - we don't have confusion between running things from
> different libraries (I hate debugging tools such as JBuilder settings
> instead of Java).
>
> But once we realize that this doesn't fit our new environment, it's
> easier to have real small components. I want to look at a "program"
> that is small and concise. CoBOL isn't small and concise. If you
> want a big program that is clear, CoBOL excels, but small components
> can be clear much more easily.

Good points.

Of course, in online environments, on mainframes, using COBOL, "small" has
been "beautiful" for as long as I can remember. :-)

The same idea carries over into Client/Server.

A very wise man, in a long-ago time and a different space, explained it to
an eager young COBOL programmer, thus:

Three factors govern online response in ANY system (well, NEARLY
any...process control systems may be excluded from the discussion):

1. Load time.
How long it takes to get the bit of code we need to execute, into a
place and state where we can execute it.
2. Queue Wait Time
How long a task is unable to get to a processor or is waiting on an
exchange jump or scheduling.
3. Capture time.
How long our task holds the CPU once it has it.

By keeping modules "small", all three of these things do better than is the
case for "large" modules.

Obviously, a large module with a small capture time MAY do better than a
small module with a large capture time, but to do so it is loading large
amounts of unexecuted code, and this has a deleterious effect on overall
system throughput.

Leaving aside batch processing (where "big" is mostly "beautiful"), smaller
code, for the most part, gives faster response.

Smaller, tighter code is easier to read and debug also.

Pete.

Howard Brazee

2007-07-10, 6:55 pm

On Wed, 11 Jul 2007 03:33:22 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Three factors govern online response in ANY system (well, NEARLY
>any...process control systems may be excluded from the discussion):
>
>1. Load time.
> How long it takes to get the bit of code we need to execute, into a
>place and state where we can execute it.
>2. Queue Wait Time
> How long a task is unable to get to a processor or is waiting on an
>exchange jump or scheduling.
>3. Capture time.
> How long our task holds the CPU once it has it.
>
>By keeping modules "small", all three of these things do better than is the
>case for "large" modules.
>
>Obviously, a large module with a small capture time MAY do better than a
>small module with a large capture time, but to do so it is loading large
>amounts of unexecuted code, and this has a deleterious effect on overall
>system throughput.
>
>Leaving aside batch processing (where "big" is mostly "beautiful"), smaller
>code, for the most part, gives faster response.
>
>Smaller, tighter code is easier to read and debug also.

But when we do a lot of stuff, it can be more efficient to have
everything in one program, where the OS makes the swapping decisions,
rather than designing our run-time linking and swapping ourselves.
Also optimizing can be better.

But the solution to these issues appears to have been to upgrade
hardware. The run-time inefficiencies of OO have been made less
important - we can afford those, and we pay for them by efficiencies
in creation cycle.

Sponsored Links