Re: Cobol for Visual sutdio

A well considered post, Bill.

I have a few comments (you knew I would... :-)) which I've sprinkled in
below...

"William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
news:d7***.196891$ZW7.91748@xxxxxxxxxxxxxxxxxxxxxxxxx
Concerning the interchange between Michael Wojcik and Pete Dashwood
(snipped in this note)

As someone with an historical bias toward both COBOL and Micro Focus (<G>
not MicroFocus), here is what I come away with from the exchange:

Sorry, I get so used to camel case I do it unconsciously. I'll separate the
words in future. :-)


1) Each release of Micro Focus products for the .NET environment provides
more and more support for those programming language and development
features that are available for other languages (especially C#) in the
VisualStudio and .NET development and deployment environments.

Yes. I was very impressed with Michael's response showing what MF actually
CAN do. I still think LINQ is important, but that is something MF may yet
provide.


2) If there are existing features that current (or prospective) customers
might want/need, then MF seem response in providing the language and
environment features.

Agreed.


3) Obtaining the development environment for C# (with VS and .NET) is
relatively inexpensive.

No, it's free. That isn't "inexpensive"... that's FREE!

And you CAN produce useful applcations with the Express (free) versions of
C# and VS. I did so, and was so impressed I bought the upgrades, mainly to
give me more productivity rather than added features (although there are
some of those too...) THAT's "inexpensive" compared ot the alternatives.


Running such applications on single machines or in network environments is
FREE (but does assume a .NET environment).


The .NET environment is a free download. Future OSs from MS are likely to
include it under the covers.

4) Obtaining the Micro Focus (for .NET / VS) development environment is
expensive. Deploying such applications to single machines is expensive;
deploying it to unlimited environments is VERY expensive.

Yes, that is my major beef with it. However, MF have to make a living and
because the COBOL marketplace is comparatively small (and getting smaller)
the cost of COBOL from any vendor HAS to be realistic.

The REAL cost of COBOL is the labour intensive ongoing maintenance of source
code. It takes too long, needs specific skills that are not readily
available, and is self defeating. Maintenance causes more errors, and if you
maintain code long enough it becomes "unmaintainable". More and more COBOL
shops are closing down because of this. They have other options. Maintaining
objects is quicker, easier, and less error prone. You can afford to drop an
object or rewrite it, you can't necessarily afford to drop a large
monolithic program which is at the heart of your business. See discussion
about "granularity" elsewhere...


5) Converting existing procedural COBOL business logic to C# (or Java) or
any other non-COBOL language (and non-COBOL OO environment) is both
expensive and error-prone. (I understand their are more and more
automated "solutions" to this, but I am unaware of any "major mainframe -
for example - application" success stories using truly automated
solutions.

Well, the guy in the video I referenced recently doesn't agree. He quoted a
number of prestige companies who moved COBOL off their IBM mainframes and
onto the network. He specialises in doing this and considers it a simple
straightforward exercise using either Fujitsu or Micro Focus toolsets. He
mentioned that he sat on the COBOL committee; I expect you know him, Bill.

I think the idea of moving CICS to the Web would give some people pause...
others would jump at the chance.

I guess it depends what you mean by "truly automated".


*IF* (admittedly questionable) one has a large COBOL base of existing
(procedural) code AND an adequate trained programming force, then
transitioning to COBOL (even OO COBOL) with .NET / VS is significantly less
resource intensive then a conversion to another language and paradigm.

At first I thought this was not a good idea, but I'm starting to mellow on
it. It does keep the business running while people pick up new skills and
concepts. I think the transition to OO COBOL could be good for key functions
in the Business Layer, and it DOES allow those functions to run with new
classes and objects in the new end-point environment.

It really comes down to what the business can afford.

to maintain (and enhance) an existing COBOL base of applications but can
(easily? cheaply?) find an adequate supply of C# programmers, then a
migration AWAY from COBOL *sooner* than later seems both advisable and
cost effective.

A number of smaller business are coming to this conclusion. According to job
sites in this part of the world, it is much easier to find a C# programmer
than a COBOL one. There are many more C# vacancies. Robert posted something
along the same lines for the US.

The thing is to try and leverage as much as possible of the existing Legacy.
You don't necessarily want to simply rewrite your application from scratch
in C#. Fortunately, you don't have to. My Migration model addresses this,
and the tools I have written and am writing are designed to support that
model.

***

Bottom-Line:
I see *no* overwhelming reason why a shop would/should do significant NEW
development in Micro Focus or any other COBOL product - unless they have a
fully trained "new style" COBOL development force and no C# or Java (or
other "new language" programming staff - or if they are doing so for an
IBM mainframe only deployment environment.

I agree. And I would be expanding the skill sets of the existing staff. (At
the very least Object Oriented concepts, OO COBOL, and ideally, Java and
C#.) Even in an IBM mainframe shop.


For shops with sufficient COBOL development staff and a large base of
existing COBOL applications, then moving to a COBOL .NET environment (and
I think Micro Focus beats Fujitsu on this - but others may disagree), then
it is a question of whether the cost of conversion (of staff and
applications) outweighs the (significant) cost of implementing a Micro
Focus development and deployment environment.

It is arguable as to which is better. Both companies offer useful tools for
migration. Fujitsu's NeoKicks (despite the appalling name :-)) is a very
good tool, judging by the videos (I have never personally used it).

I think you covered the real question: What's it gonna cost, and what are
the benefits?

For the scenario you outlined here, WHATEVER they do is going to cost. Their
instinct is therefore to maintain the status quo. However that is probably
not viable either, definitely not in the long run.

Personally, as a mid point in this scenario I'd go to the Fujitsu
environment because it doesn't cost me to deploy and run it. But there is
another thing we haven't looked at. If the existing COBOL they are running
supports OO, then there is no need to migrate any COBOL. All they have to do
is refactor it into OO components and they can move directly to .NET and C#.
This could be a very effective way of getting to the .NET endpoint, WITHOUT
needing to buy ANY "alternative COBOL"s.

I see "language capabilities" as irrelevant.

Depends what they are...and what you are trying to do :-)

For example, I think LINQ is important. Certainly, if you intend to deploy
new devices that run parallel processors, if you have mission critical
applications that are largely database dependent, if you want to use
functional programming (Lambdas) to get deferred JIT DB access and
optimization, and if you want to be able to access new data storage devices
with emerging technologies in a simple and consistent way, then LINQ is
worth having a look at. Presently it is integrated in C# only. (Language
INtegrated Queries). LINQ is to SQL as mammals are to reptiles. For current
databases which require SQL, LINQ generates optimized SQL; for future
databases and devices it may generate other stuff. As a programmer I
shouldn't be concerned about the SQL any more than a COBOL programmer cares
what constructs are generated by the compiler; you trust it to produce
optimized code. You don't change your COBOL when a new processor with a
different instruction set hits the marketplace; you trust the compiler to
have it covered.


I *do* see the "free run-time environment" of Fujitsu to be a valid
consideration for those wishing to stay with COBOL in a .NET (VS)
environment, but (personally) just as Fujitsu has NOT stayed current with
its IBM dialect support, I do not see them staying current (or as current)
with .NET as MF does, so this run-time price advantage is (to me) probably
insufficient reason to select it over MF in a rapidly changing .NET
(Microsoft, PC, etc) deployment environment.

Again it depends... I have never been affected by Fujitsu's "failure" to
keep up with IBM dialect support. I'd be interested to hear what a Fujistu
spokesperson might say about that :-) If you use C# there is no problem
anyway.

Some glimpses of the forthcoming release of C# have been made public this
week. People who are interested might check out:
http://reddevnews.com/blogs/print.aspx?blog=2885

Anders Hejlsberg (the creator of C#) talks about new features in Release 4.
Of particular interest for Migrations is the improved support for COM
components. (Actually, support for them is not bad currently, using InterOP
Services, as we did for the COBOL structure Tool, but it can be tedious if
you have to do type casting between C# and COM)


It is NOT surprising (given the above) that the MF target audience (even
for .NET) and especially their development AND DEPLOYMENT pricing/costs is
targeted at large existing COBOL (probably IBM mainframe) shops. For
them, that solution *is* cost effective; for individual (and small ISV)
developers, the "stay with COBOL" solution wouldn't be cost effective at
any price that MF could stay in business with.

Yes, I think that's fair.

I'd like to explore the "IBM mainframe" shop options a bit more though...

Perhaps in another thread. :-)

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


.

Quantcast