<disclaimer>
Please note:
None of my comments are meant to state or imply that there is anything
negative about SPL, SPLash!, Java, Visual BASIC, or any other programming
language.  If you use one of the languages I refer to below, please do not
take offense at any comparisons -- no offense was intended.
</disclaimer>

I don't see COBOL going away anytime soon, and I'm not a COBOL programmer
-- I haven't written a COBOL program in almost 15 years (even worse, I'm an
SPL/SPLash! person -- talk about your dead-end languages!).

I noted with interest the COBOL 2000 initiatives, and my reaction was one
of "yeah! it's about time".  There ARE TONS of COBOL applications that are
out there.  Some have their roots in COBOL programs from the 60's and have
been enhanced again and again to incorporate new features and
functionality, to make use of new compilers and language functionality, and
migrate from IMAGE with no CIUPDATE to IMAGE with CIUPDATE.

Have the COBOL programs been put out to pasture?  Mostly no.  Have they
survived "client server" initiatives?  Mostly yes.

The greatest impediment I see to the continued survival of COBOL is that
the majority of the COBOL programmers I see are using only a fraction of
COBOL's features and capabilities, and almost none are willing to consider
designing and coding an application that needs to communicate with a PC or
other platform.  They won't touch NETIPC, refuse to even consider handling
byte stream files, and begin searching for wooden stakes, silver bullets,
and large crosses when you mention coding a CGI interface.

From what I can see, the COBOL's survival is less a problem of what CAN be
done in COBOL, and MORE a problem of the mindset of the the majority of
COBOL application designers and coders.

Also, you have to have new COBOL programmers entering the field to replace
COBOL programmers who are retiring or the language starts to die.

Part of that problem appears to stem from the educational system.  COBOL
isn't in vogue.  Who teaches COBOL at the university level anymore?  Look
at a university course catalog and you are more likely to see classes in C,
Visual BASIC, or Java.  Read the course descriptions and objectives of the
classes.  First, there will be higher-level classes in Visual BASIC and
Java.  I'll bet that in the upper-level Visual BASIC class the emphasis
will be on writing a little GUI program that communicates with a server the
instructor has coded; the upper-level Java class will be working with Java
script html pages and server-based Java code interacting with a database on
a server; and that the COBOL class will be reading from flat files,
outputting to the line printer, and not much more.

Okay, so why has this happened, and what can be done to reverse the trend?

First, the university that I'm most familiar with goes with trends, but
also looks for classes that are "new" or "different" from the offerings of
other universities nearby.  What often happens is that as a project at a
local company reaches the production stage and the programming and analysis
staff begin returning to 40 hour weeks, one of the staff members will
approach the university with the idea of teaching a course that instructs
others in how to design and implement similar "business solutions" based
upon the "new technology" the company has developed.  Often the "new
technology" isn't so new, and people have been doing the same thing for a
couple of years.  What is new is that someone is finally willing to spend
the time it takes to develop a new course and then make the commitment to
teach the course.  You have seen all those courses and books that speak to
using Java for this or for that, but when (and where) have you seen a
course or book on "Using COBOL in an Internet Driven World", or "Writing
COBOL CGI Interfaces", or "COBOL, ODBC, and You", or "Sockets Programming
from COBOL"?

Second, you have to have people who KNOW the material, have experience with
the technology and techniques and can answer students questions.

Third, you have to have instructors who can TEACH.  Not everyone can teach,
and many fantastic courses are bogged down with instructors who were very
bright and know the subject from A to Z, but can't explain the material to
save their soul!

Fourth, you have to have an audience for the course.  Universities know
this.  If they think industry no longer uses COBOL or needs COBOL
programmers, they won't offer COBOL classes.  Band together with other
COBOL shops and put pressure on the local university to generate
COBOL-literate graduates.

Fifth, the course title and course syllabus (as they appear in the
"schedule of classes" and "course catalog") can make or break a course.
The title and syllabus need to grab attention and make people want to take
the course.  Unfortunately, many academics consider COBOL a dirty word,
sort of like BASIC was until Visual BASIC came along.  [shudder, gasp,
etc.] Do we need Visual COBOL to make COBOL an "in" language?

So, there are some challenges.  Get your COBOL analysts and programmers
working with web, sockets, and ODBC technologies.  Find the COBOL shops in
your area.  Get them to write a joint letter to the local university
stating that they need more people with COBOL experience, and not just
COBOL experience of the "read a record, write the record to the printer"
kind, but experience designing and coding web enabled applications, sockets
applications, etc. -- all the sorts of things that are often done in C but
CAN be done in COBOL.  If the local university can't find people to teach
the classes, motivate some of your employees who show some teaching
aptitude to teach part time at the local university - it actually can be fun.

John


At 11/2/98 03:27 PM , RON HORNER wrote:
>I was asked, not too long ago,  what I thought about COBOL being a dead
>language.  I took a step back and gave my option, that it's not a dead
>language.  I continued by suggesting that the rumors of this death was
>created by frustrated academics with too much time on their hands and
>not enough creativity to find something to do.
>
>I guess all of this defending of a programming language that I love,
>sparks a question.  Is COBOL really dead?  If it is what replaced it, or
>should replace it?  If it's not, what improvements are being made to it?
>And for those who think that the life expectancy of COBOL is dropping,
>how do we pump it up.
>
>COBOL was the first programming language I learned.  To this day, I
>always try to use it as a programming solution.  What are your thoughts.
>
>Later.
>

--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.

The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.