Could this save COBOL?

I have been looking more closely at Fujitsu COBOL for .Net.

This is really an excellent product (on paper; I haven't tried it yet...)
and adds OO COBOL to the Visual Studio IDE so that a developer can use any
of the popular languages for the MicroSoft platform (C++, VB, C#). Dot Net
COBOL has all the same benefits (editor, automatic build tracking, version
control, project organisation, full debugging facilities) that the other
languages enjoy and you can mix and match, developing classes (or .NET
components) in any of these languages.

It would be fairly easy to 'refactor' existing COBOL code for mainframe
using this environment and Fujitsu are also offering a CICS converter.

So, why would people not use it?

The main obstacles I see are as follows:

1. The mainframe sites are not into OO.  The Dot NET environment is all
about using Dot NET classes and objects and many IT Managers are going to be
wary of upskilling their people, even though this is an ideal growth path
for traditional mainframe programmers.

2. The product is not cheap. That means that small software houses and
independents won't get the chance to experiment with it, or discover the
full benefits of it. (The free trial is for 5 days, not anywhere near long
enough to evaluate all the facilities offered. I believe it can be extended
by agreement with Fujitsu but that would be decidedly dodgy ground, in my
opinion)

3. Fujitsu support has established itself as being abysmal. One would hope
that with this product, that would be remedied and addressed, but it remains
to be seen.

4. Service Oriented Architecture (which this product provides excellent
support for) is still a mystery on mainframe sites where traditional COBOL
is still in use. The 'smart' people who are getting into this, tend to be
'Non-microSoft' users and, for them, Dot NET is of little interest anyway.
(IBM's approach is primarily via Java servlets). Yet, SOA can be implemented
very well in a Dot NET environment, and this product is ideal for doing just
that.

In the final analysis, it comes down to whether COBOL is still considered to
be viable. I'm re-evaluating this. Certainly OO COBOL can be used just as
easily as any other language, but the people who you might expect to use it,
don't want to...:-)

I still believe that COBOL as the only game in town is finished. But
products like Fujitsu's Net COBOL for Dot NET could possibly allow it to be
reinvented as a tool for refactoring existing code and for building SOAs
from existing systems. I understand that MicroFocus are providing a similar
product also, but I don't know the details.

Both companies must believe there is a hopeful market for it. If there
isn't, then they will sustain considerable losses. (The R & D could not have
been cheap...)

What do you guys think?

A. COBOL will continue as it always has, being procedural code with source
code maintained and central to all development.

B. Companies will stop ALL IT development (including COBOL) and simply use
packages, or outsource. The IT department is really just Network management,
with network nerds making sure the network stays up so people can share
spreadsheets, databases, and email, and rolling out new operating systems
when required. No inhouse development.

C. OO COBOL will be used to refactor existing source code into reusable
components. Probably as the basis for a SOA.

D. Existing systems written in COBOL will simply be replaced over time.
In-house support for COBOL will be dropped.

D. COBOL will have some other role, not described above.

Pete.

Answering your last question first (and ignoring the fact that you have two
option D's <g> ), direction in my shop seems to be your first D, just age out
the applications and replace with non-COBOL. The project I'm working on now
intends to replace the two major COBOL apps that we support and replace them
with a Java framework application. I also see a progression towrds B with
more outsourcing but it's mostly a people issue. (Note-I work for a State
government agency so we may have a few unique characteristics, in particular
the difficulties in recruiting ANY new programmers coupled with existing
workforce retirements. Can't rule out political motivations either.) I will
also add that SOA does not require (neccesarily) OO programming although we
could sink into other debates as to what exactly is SOA.

As for your comments on Fujitsu .NET I have to say that I have never worked
with the product. However, I have tinkered with Micro Focus' NetExpress for
.Net so there may be some commonality. My personal feeling was that the
transition to OO COBOL was going to be a little jarring. Although I
understand OO principles and have written VB.NET apps, getting the hang of
the OO COBOL syntax was not easy. There is also the odd aspect that if I
didn't already know OO COBOL, that trying to learn it rather than VB.NET or
C# for new development seems counterproductive, especially since there seems
to be little demand for OO COBOL skills compared to other .NET language
skills. In other words, if I already knew another .NET language then I saw
little benefit in dragging COBOL with me. (And I LIKE COBOL!)
The exception to this, and something we were interested in doing, was
rehosting existing procedural COBOL logic (especially subroutines) into .NET
components. Using the MF tools there were a couple of ways to accomplish it
but neither were quite what we had in mind. MF did plan to (and perhaps
already has, my eval was awhile ago) extend the Interface Mapping Toolkit to
support mapping procedural COBOL linkage sections with a .NET object
interface. That would have fit the bill at least in theory.


"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4m3tcaF4ec3fU1@individual.net...
>I have been looking more closely at Fujitsu COBOL for .Net.
>
> This is really an excellent product (on paper; I haven't tried it yet...)
> and adds OO COBOL to the Visual Studio IDE so that a developer can use any
> of the popular languages for the MicroSoft platform (C++, VB, C#). Dot Net
> COBOL has all the same benefits (editor, automatic build tracking, version
> control, project organisation, full debugging facilities) that the other
> languages enjoy and you can mix and match, developing classes (or .NET
> components) in any of these languages.
>
> It would be fairly easy to 'refactor' existing COBOL code for mainframe
> using this environment and Fujitsu are also offering a CICS converter.
>
> So, why would people not use it?
>
> The main obstacles I see are as follows:
>
> 1. The mainframe sites are not into OO.  The Dot NET environment is all
> about using Dot NET classes and objects and many IT Managers are going to
> be wary of upskilling their people, even though this is an ideal growth
> path for traditional mainframe programmers.
>
> 2. The product is not cheap. That means that small software houses and
> independents won't get the chance to experiment with it, or discover the
> full benefits of it. (The free trial is for 5 days, not anywhere near long
> enough to evaluate all the facilities offered. I believe it can be
> extended by agreement with Fujitsu but that would be decidedly dodgy
> ground, in my opinion)
>
> 3. Fujitsu support has established itself as being abysmal. One would hope
> that with this product, that would be remedied and addressed, but it
> remains to be seen.
>
> 4. Service Oriented Architecture (which this product provides excellent
> support for) is still a mystery on mainframe sites where traditional COBOL
> is still in use. The 'smart' people who are getting into this, tend to be
> 'Non-microSoft' users and, for them, Dot NET is of little interest anyway.
> (IBM's approach is primarily via Java servlets). Yet, SOA can be
> implemented very well in a Dot NET environment, and this product is ideal
> for doing just that.
>
> In the final analysis, it comes down to whether COBOL is still considered
> to be viable. I'm re-evaluating this. Certainly OO COBOL can be used just
> as easily as any other language, but the people who you might expect to
> use it, don't want to...:-)
>
> I still believe that COBOL as the only game in town is finished. But
> products like Fujitsu's Net COBOL for Dot NET could possibly allow it to
> be reinvented as a tool for refactoring existing code and for building
> SOAs from existing systems. I understand that MicroFocus are providing a
> similar product also, but I don't know the details.
>
> Both companies must believe there is a hopeful market for it. If there
> isn't, then they will sustain considerable losses. (The R & D could not
> have been cheap...)
>
> What do you guys think?
>
> A. COBOL will continue as it always has, being procedural code with source
> code maintained and central to all development.
>
> B. Companies will stop ALL IT development (including COBOL) and simply use
> packages, or outsource. The IT department is really just Network
> management, with network nerds making sure the network stays up so people
> can share spreadsheets, databases, and email, and rolling out new
> operating systems when required. No inhouse development.
>
> C. OO COBOL will be used to refactor existing source code into reusable
> components. Probably as the basis for a SOA.
>
> D. Existing systems written in COBOL will simply be replaced over time.
> In-house support for COBOL will be dropped.
>
> D. COBOL will have some other role, not described above.
>
> Pete.
>
>
>
>
>
>

In article <4m3tcaF4ec3fU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>I have been looking more closely at Fujitsu COBOL for .Net.

[snip]

>What do you guys think?

I can barely speak for *myself*, let alone for others... but if I were
much good at predicting the future I'd make my living in the stockmarket.

(At present I do *not* make my living in the stockmarket... and, in fact,
by making simple 'mental investments' ('Hmmmmm... that looks good, let me
make a mark that I've bought (n) shares of Widgetco at price (US$y)') it
seems as though I can cause a worldwide recession.

DD

Thanks for an interesting and informative response, Douglas.

Comments below...

"Douglas Gallant" <no@spam.net> wrote in message
news:PN5Lg.36283$uH6.3224@twister.nyroc.rr.com...
> Answering your last question first (and ignoring the fact that you have
> two option D's <g> ),

Sorry, it was a typo... let's call that option E... :-)


> direction in my shop seems to be your first D, just age out the
> applications and replace with non-COBOL.

Interesting. I don't know any places that are doing that, but it doesn't
surprise me.

>The project I'm working on now intends to replace the two major COBOL apps
>that we support and replace them with a Java framework application.

Are they using Open Source or is this a MS shop?


> I also see a progression towrds B with more outsourcing but it's mostly a
> people issue.

Yes, I see companies here doing that as well.


> (Note-I work for a State government agency so we may have a few unique
> characteristics, in particular the difficulties in recruiting ANY new
> programmers coupled with existing workforce retirements. Can't rule out
> political motivations either.) I will also add that SOA does not require
> (neccesarily) OO programming although we could sink into other debates as
> to what exactly is SOA.

Sure. Let's leave that aside for now.

>
> As for your comments on Fujitsu .NET I have to say that I have never
> worked with the product. However, I have tinkered with Micro Focus'
> NetExpress for .Net so there may be some commonality. My personal feeling
> was that the transition to OO COBOL was going to be a little jarring.
> Although I understand OO principles and have written VB.NET apps, getting
> the hang of the OO COBOL syntax was not easy.

Yes, I found the same problem when I first started using it. I gave up and
learned Java instead. Then went back to OO COBOL and it all seemed to fall
into place miraculously. :-) I think it is about concepts. Syntax can be
learned in ANY language (evenAPL,  if you have a few billion brain cells to
spare and don't have a girl friend or a life... :-))



>There is also the odd aspect that if I didn't already know OO COBOL, that
>trying to learn it rather than VB.NET or C# for new development seems
>counterproductive, especially since there seems to be little demand for OO
>COBOL skills compared to other .NET language skills.
See, this raises a very important point. Should we, as programmers, learn a
language primarily because it is a marketable skill, or because we think it
might be useful for the work we need to do?

Obviously, most people want to be as marketable as possible, so they have a
good eye in this direction.

Nothing wrong with that.

I have been using Visual Studio to put apps together and this means mainly
VB or C# (I just can't warm to C++; in some ways it seems limited and
clunky...just a personal thing :-)) I haven't invested a lot of time in
learning C# and won't until its future is quite clear. But COBOL, given a
level playing field in the Dot NET arena, could be very useful. Especially
as I have a large investment in it already...

>In other words, if I already knew another .NET language then I saw little
>benefit in dragging COBOL with me. (And I LIKE COBOL!)

Yep, I completely understand and agree. But I'm realising there are times
when it would be good to have COBOL in the playground and playing nicely
with the other kids... :-)

> The exception to this, and something we were interested in doing, was
> rehosting existing procedural COBOL logic (especially subroutines) into
> .NET components. Using the MF tools there were a couple of ways to
> accomplish it but neither were quite what we had in mind. MF did plan to
> (and perhaps already has, my eval was awhile ago) extend the Interface
> Mapping Toolkit to support mapping procedural COBOL linkage sections with
> a .NET object interface. That would have fit the bill at least in theory.
>
Fujitsu is very strong in this area and makes it pretty simple. I especially
like their SOA interface. You can create a NET object from your old COBOL,
then wrap it as a Web Service, just by selecting options... pretty 
really.

>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4m3tcaF4ec3fU1@individual.net... 

Thanks for the insight into what's happening where you are,

Pete.












 
>
>

<docdwarf@panix.com> wrote in message news:edjfhe$6ri$1@reader2.panix.com...
> In article <4m3tcaF4ec3fU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote: 
>
> [snip]
> 
>
> I can barely speak for *myself*, let alone for others... but if I were
> much good at predicting the future I'd make my living in the stockmarket.

So what about the present? Is anyone talking about any of the options laid
out...?

>
> (At present I do *not* make my living in the stockmarket... and, in fact,
> by making simple 'mental investments' ('Hmmmmm... that looks good, let me
> make a mark that I've bought (n) shares of Widgetco at price (US$y)') it
> seems as though I can cause a worldwide recession.

At least in your own mind, Doc... :-)

Pete.

In article <4m559aF47ocgU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:edjfhe$6ri$1@reader2.panix.com..
. 
>
>So what about the present?

Hmmmm... at present I'm waiting for the tea to get done steeping so that I
might have a fresh cup of Bai Mu Dan.

>Is anyone talking about any of the options laid
>out...?

I try not to eavesdrop... but, most likely, someone, somewhere is doing
that, aye.

> 
>
>At least in your own mind, Doc... :-)

I'm not sure where 'seeming' exists outside of any mind, Mr Dashwood.

DD

Douglas Gallant wrote:
>
> As for your comments on Fujitsu .NET I have to say that I have never worke
d
> with the product. However, I have tinkered with Micro Focus' NetExpress fo
r
> .Net so there may be some commonality. My personal feeling was that the
> transition to OO COBOL was going to be a little jarring.

There is no requirement - with the Fujitsu or the Micro Focus product
offerings for .NET, to use or utilize OO syntax or constructs.
Traditional COBOL programs can be compiled and used with the offerings
without refactoring or a change in syntax or adoption of OO.

In article <4m3tcaF4ec3fU1@individual.net>, "Pete Dashwood" <dashwood@enternet.co.nz> write
s:
>
> This is really an excellent product (on paper; I haven't tried it yet...)
> and adds OO COBOL to the Visual Studio IDE so that a developer can use any
> of the popular languages for the MicroSoft platform (C++, VB, C#). Dot Net
> COBOL has all the same benefits (editor, automatic build tracking, version
> control, project organisation, full debugging facilities) that the other
> languages enjoy and you can mix and match, developing classes (or .NET
> components) in any of these languages.

If I may toss in an interested metastasis: Micro Focus Net Express
for .NET, and the upcoming Micro Focus Studio, also provide an OO
COBOL as a first-class .NET language with Visual Studio integration.

--
Michael Wojcik                  michael.wojcik@microfocus.com

Even 300 years later, you should plan it in detail, when it comes to your
summer vacation.  -- Pizzicato Five

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4m3tcaF4ec3fU1@individual.net...
>
> C. OO COBOL will be used to refactor existing source code into reusable
> components. Probably as the basis for a SOA.
>
> D. Existing systems written in COBOL will simply be replaced over time.
> In-house support for COBOL will be dropped.

I've seen a project where the environment around the COBOL app is
emulated, so that the COBOL program thinks it's running as intended, but
actually it's providing the backbone for a SOA web app: A lot of
screen-scrapping is done, and the output from COBOL is parsed and
transformed into HTML or XML as appropriate; Access to files is intercepted
and transformed into returning hardcoded string values, or connections to
remote databases, etc.

I assume they're going through all this trouble because the original
source code is lost or something.

- Oliver

Pete Dashwood wrote:

imho, nothing, but nothing can or will save Cobol.
It'll wither on the vine & no-one will particularly miss it
during their day job.

It's not being taught in college / university; new recruits
will quite reasonably balk at the idea of learning this old
language, too.

Yes, there are still 'trillions' of lines of Cobol source out
there, but less trillions than there used to be; a trend that's
not going to reverse.

If only there were a 'nice' language out there - just one
major, straightforward, popular language ... you know, as Cobol
used to be!

Regards

Michael

>...)
>
> What do you guys think?
>
> A. COBOL will continue as it always has, being procedural code with source
> code maintained and central to all development.
>
> B. Companies will stop ALL IT development (including COBOL) and simply use
> packages, or outsource. The IT department is really just Network managemen
t,
> with network nerds making sure the network stays up so people can share
> spreadsheets, databases, and email, and rolling out new operating systems
> when required. No inhouse development.
>
> C. OO COBOL will be used to refactor existing source code into reusable
> components. Probably as the basis for a SOA.
>
> D. Existing systems written in COBOL will simply be replaced over time.
> In-house support for COBOL will be dropped.
>
> D. COBOL will have some other role, not described above.
>
> Pete.