Cobol - PowerCOBOL conversion to DotNET

Author

PowerCOBOL conversion to DotNET

Pete Dashwood

2008-03-12, 3:55 am

I am looking for expressions of interest from sites who currently use
PowerCOBOL but need to get their existing applications onto .NET.

Purchasing Fujitsu COBOL for .NET may not be a solution...

1. It is expensive.
2. It doesn't implement the full COBOL standard, or even the standard
implemented by PowerCOBOL, so some existing constructs may not work.
3. It ties you in to COBOL at a time when you may want to be moving away
from it.
4. Have you used Fujitsu support recently?

WHAT I'M PROPOSING:

1. Convert existing PowerCOBOL apps to the .NET framework using C# as a
wrapper. (C# Express and Visual Studio Express are currently free; this
probably won't last for ever...The Express editions are quite adequate to
maintain your converted apps.)
2. Event and script processing would still be in your existing COBOL and
could be maintained by your existing programmers using your existing
NetCOBOL compiler. A conversion tool will extract and isolate all of this
code into COM components which you can maintain with NetCOBOL. These
refactored COBOL components would simply be wrapped and viewed by .NET as
unmanaged code. (I have done some extensive experiments in this area and got
it working. It is feasible and viable.)
3. Your existing PowerCOBOL Forms would be converted to .NET forms and the
event processing would be wrapped and run by C#.
4. Your existing ISAM data can be converted to Relational Database as part
of the .NET conversion.
5. You may need to tailor your exising ISAM Access to SQL. I can assist
here but cannot undertake full code conversion (unless you pay me
significant sums of money... :-))

The end result is an existing application running in .NET with full database
access and GUI. It should be viewed as an interim system while your team
learn C#... On an ongoing basis you can replace COBOL script components with
whatever language you want (I recommend C# but you COULD use Java...or
anything else that can do the required functionality.) So your existing
PowerCOBOL application gets moved into the 21st century, and you have a
growth path for further development.

..NET apps can be easily Web enhanced; PowerCOBOL apps can't be.

I would like to see this being done for a few hundred bucks per application
(PowerCOBOL Project), but it obviously depends on how many Projects are
candidates for conversion.

WHAT I NEED:

Before undertaking to build the tools needed for this conversion I need to
know that it is worth doing. The larger the potential customer base, the
cheaper the solution will be...

If you are thinking about modernizing your existing PowerCOBOL apps., please
email me with the number of PowerCOBOL projects you would be looking at
migrating to .NET, and an estimate of the number of ISAM files that are
involved.

I'll hold this offer open for two w

s. At the end of that time, I'll mail
everyone who responded, with a ballpark price for doing their migration, and
an estimate of when the code could be available. There is no obligation. You
either proceed or you don't, no problem.

Obviously, your confidentiality will be respected and nobody except yourself
and me will know whether you responded or not.

Think about it, and mail me.

Pete.
--
"I used to write COBOL...now I can do anything."

Robin Lee

2008-03-13, 6:56 pm

Pete - I'm moving our apps slowly and gradually to C#, based primarily on some
things you've said in the past in this forum. These days I don't know just what to
recommend to management. Our core apps are screen driven COBOL from the seventies,
which have been converted and migrated across six different platforms over the past
three decades. Formerly I had been a strong proponent of COBOL for precisely that
reason... relative hardware independence. Moving to another system involved
modifying screen behavior and some minor differences in file system hosting (i.e,
the behavior of ISAM on whatever database system upon which it is implemented).
Never simple but always do-able.

Consequently, the core algorithms - the processing guts - could remain untouched,
except where needed in order to accommodate changing business needs. The rest of the
code however has been adulterated with kludge upon kludge to make it fit whatever
platform we happened to be running on for the time being. Our most recent conversion
was to SQL server using ADO with some help from you and Frederico. But whether or
not Microsoft will be the platform of choice another decade from now is not certain.
Same can be said for C#. So I'm not entirely sold.

Note that what the programs actually do hasn't changed. Not that a rewrite hasn't
been tried before. Earlier this decade, I was canned and another team brought in to
rewrite the most important apps in a more "modern" language (read VB). Disastrous.
Just seeing the results of someone's attempt to write a bill of materials explosion,
which is essentially a mere training exercise when done in COBOL with ISAM - using
in-memory tables and bubble sorts is almost humorous.

Now I'm back in, and they're asking me what to do. Unfortunately I can no longer
recommend COBOL. Not because it can't do the job, but because it's becoming less and
less likely to remain viable. It sounds to me like your approach is yet another stop
gap approach... essentially the same thing we've been doing for the past 30 years.
Good luck in your endeavor. I can see where this would be a handy short term
solution for those with large volumes of code. We've already been there and done it.
Not using your technique, but with the same result.

Pete Dashwood

2008-03-13, 9:55 pm

"Robin Lee" <robinlee@news.com> wrote in message
news:h5Wdnfw9o_SqLUTanZ2dnUVZ_veinZ2d@gi
ganews.com...
> Pete - I'm moving our apps slowly and gradually to C#, based primarily on
> some things you've said in the past in this forum. These days I don't know
> just what to recommend to management. Our core apps are screen driven
> COBOL from the seventies, which have been converted and migrated across
> six different platforms over the past three decades.

Ouch!

Formerly I had been a strong proponent of COBOL for precisely that
> reason... relative hardware independence. Moving to another system
> involved modifying screen behavior and some minor differences in file
> system hosting (i.e, the behavior of ISAM on whatever database system upon
> which it is implemented).
> Never simple but always do-able.
>
> Consequently, the core algorithms - the processing guts - could remain
> untouched,
> except where needed in order to accommodate changing business needs. The
> rest of the code however has been adulterated with kludge upon kludge to
> make it fit whatever platform we happened to be running on for the time
> being.

Maybe others can learn from this experience; SEPARATE applications into
tiers. Each tier is a layer:

1. Presentation layer. Handles the User interface. It might be GUI, it
might be speech, it might be VR... whatever it is, for output, it is driven
from a shared data buffer which is "filled" from the second tier (business
logic), for input, it does whatever validations are required and passes
VALID data into the second tier.

2. Business Logic Layer. Its inputs are the buffers from the presentation
layer, it processes, and returns outputs to the presentation layer.

3. The Data Layer. Doesn't matter whether it is ISAM, VSAM, Hierarchical,
Network, or Relational Database, it simply deals with managing data. This
tier provides a service to the other two layers. Again, all inputs and
outputs to/from it are by means of in-memory buffers. NO other layer should
contain data access or manipulation code embedded in it; instead, calls
should be made to this layer to provide the data service.

While the above is idealistic and pretty hard to achieve in practice, the
closer you can get to it, the less aggravation you will encounter when it
comes to platform change.

>Our most recent conversion was to SQL server using ADO with some help from
>you and Frederico. But whether or not Microsoft will be the platform of
>choice another decade from now is not certain.

Absolutely. In IT few things are ever certain. However, choosing the most
popular platform means that you have more collective clout, more available
support, and less chance of going under. Sadly, just like Betamax and VHS,
the most popular is not always the best...

> Same can be said for C#. So I'm not entirely sold.

Moving to C# is not really about the language; it is more about the
platform. .NET/Mono provides a level playing field where different
components, developed with different languages, can interact seamlessy and
transparently with each other, and play nicely together. C# is simply a very
effective vehicle into the .NET framework. (It is also a more powerful
language than COBOL, though...)

>
> Note that what the programs actually do hasn't changed. Not that a rewrite
> hasn't been tried before. Earlier this decade, I was canned and another
> team brought in to rewrite the most important apps in a more "modern"
> language (read VB). Disastrous. Just seeing the results of someone's
> attempt to write a bill of materials explosion, which is essentially a
> mere training exercise when done in COBOL with ISAM - using in-memory
> tables and bubble sorts is almost humorous.

Probably not funny for the people who did it, but I take your point :-)
>
> Now I'm back in, and they're asking me what to do. Unfortunately I can no
> longer recommend COBOL. Not because it can't do the job, but because it's
> becoming less and less likely to remain viable.

Yes,

ly, that is the reality.

Nevertheless, it would be a pity to throw out the baby with the bath water.
I'd try to encapsulate and isolate that COBOL business logic, maybe build it
into COM components . (COM seems to have weathered the storms of change
remarkably well and most modern OO languages can interface to it pretty
easily. This means you can leverage your existing code into the new
environment and is one of the foundations of my proposal. Fortunately the
refactoring can be largely automated (at least, it can be in the Fujitsu
environment) and you end up with a series of COM components that can be used
on the web or on the desktop and can run in the .NET environment.

>It sounds to me like your approach is yet another stop gap approach...

Yes it certainly is. But it is intended to keep things running while a more
long term approach can be devised and implemented.

I believe there is a difference between a planned, phased migration, which
may involve some code refactoring, and a stop gap, which is usually just
another hastily applied BandAid... :-)

> essentially the same thing we've been doing for the past 30 years.

Well, not quite, but I can understand you thinking that.Up until "recently"
we simply haven't had the possibility to refactor and encapsulate existing
functionality, in a way that allows it to be used on the Web or the desktop,
and across environments and platforms.

> Good luck in your endeavor.

Thanks. I'm not sure there will even be any endeavour. If the response is
poor it may be because people are already moving off COBOL or are happy with
a continuing COBOL solution using .NET COBOL Either way, I'm not gong to
invest a lot of time and effort into generalising and polishing approaches
that have worked for me, unless I am sure there will be SOME return on doing
so. I want to help, but I'm not stupid... :-)

I can see where this would be a handy short term
> solution for those with large volumes of code.

It would be "short term" inasmuch as it would be part of a continuing and
phased migration path.

We've already been there and done it.
> Not using your technique, but with the same result.

Maybe :-) I hope the result will not be the same... :-)

Thanks very much for your response. Good luck with a solution.

Pete.
--
"I used to write COBOL...now I can do anything."

Sponsored Links