Re: Could this save COBOL?

In response to the posting below, I have been doing a lot of thinking
about OO and the mainframe. There are a number of reasons why I think
OO had a harder time.

1. COBOL, unlike the other languages was not a major part of most
university computer curriculums. Many of the computer science
departments were a part of the mathematics department or spun off from
it. These departments were for the most part interested in solving
different problems that those addressed by the business community.

2. The management of most business IT is not interested in computing
science and is interested in solving business problems without blowing
up the world every time a change is made.

3. The large base of installed code makes change interesting. I was
on the year 2000 project at one company and for many existing systems
they retained 2 digit years because of the difficulty of changing all
the files and data bases. This client also was interested in
replacing their then current application suite but did not have a
guaranteed workable solution. I understand that 6 years later the
client is finally going to be able to cut over to a new application.

3. OO wasn't even available in the IBM arena until the early 1990's
and the support for it had the client on bleeding edge. Indeed the
initial OO support has been replaced by JAVA interfacing.

4. Repository facilities really haven't been available until
relatively recently in the IBM mainframe arena for COBOL until the
past few years and populating a repository again is interesting.

5. While runtime checking of compatibility of parameters passed
between dynamic caller and called modules was requested in the
SHARE/Guide Language Futures Task Force Report in the 1980's, I doubt
there is any such facility even today. This run-time checking is
expensive in an online environment, far less so in batch because it
only has to be done at initial bind.

6. Other mechanisms had evolved to address some of the problems that
OO is used to solve. While they are not as good, the question of
conversion cost becomes a major stumbling block.

7. In the mainframe area, many organizations were looking to replace
existing code with packages, and in many cases to get off the
mainframe. The attitude in many shops was and still is that they will
keeping the old systems limping with minimal improvement until brave
new world takes over which will be soon for some value of soon.
Organizations underestimate the difficulty of replacing even poorly
written applications. The application suite I mentioned in item 3 had
most of the people who worked on it more than willing to contribute
effort to its early demise. Both major rewrite/upgrade and
replacement can be difficult.

8. Especially prior to a few years ago, on many systems the overhead
of added intermodule checking would have killed response time. The
additional overhead of a database and increased I-O before the era of
multi-gigabyte main memory systems also was an inhibitor to converting
to a database.

9. A major change like either database or OO has to have management
interest and understanding. Databases go back to the 1970's and
relational databases to the 1980's. It has taken a long time for the
ideas to penetrate organizations and there has been far greater push
on the part of vendors to educate management on the value of database.
I might also add database is far more necessary on Windows and Unix
systems than traditional mainframes because the former do not have a
native indexed file system while the mainframes did and do. I haven't
seen the comparable push for OO in the business computing environment.

10. I know that I have looked at OO and was interested in it but have
not bothered to learn it because I would have had no opportunity to
apply the knowledge. At age 67, I don't know that I will have such an
opportunity and I suspect that any contracts I get will be because of
my "old world" knowledge. I have not been that interested in Java
because I would be less valuable than someone two years out of school
although I would welcome the opportunity to upgrade a Java based
system. I am far more of an improver and fixer than I am a creator. I
suspect that many of my younger compatriots are in the same situation.

11. Many COBOL programmers and IT managers are brought in from other
departments and their interest in moving up in the organization may
not be in IT. I am not certain that IT is a profession despite what
the Canadian Information Processing Society claims.

On Tue, 5 Sep 2006 12:06:29 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxx> wrote:

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

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

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.