Am 22.08.2014 03:25, schrieb Joel C. Ewing:
As for the coming critical shortage of COBOL programmers: I don't know
how colleges train people in IT these days, but in the old days
students were taught basic programming concepts and algorithms and
exposed to many different programming languages in order to appreciate
that no single programming language is optimal for all tasks. Once you
understood programming concepts and were functionally literate in
several languages, learning a new programming language was not that
difficult: just read a language reference manual and an introductory
text, learn how to map constructs and algorithms in known programming
languages into the new language, learn what is unique about the
language, and study existing programs. In a few days it was possible
to write simple programs in the new language and certainly in at most
a few months be competent enough to understand and potentiallly
maintain programs in the language. Unless the new generation of
programmers is much dumber than we were, I think the alarms about the
future lack of COBOL programmers is overblown. Acquiring a new
language skill is a better understood process and simpler than
teaching complex application designs unique to one installation. It
would certainly be better if younger programmers were brought on board
and introduced to COBOL applications while some of the retiring COBOL
programmers are still around, but that overlap is desireable just for
passing on knowledge about installation programming conventions,
complex application designs and inter-application relationships. If
some IT-management types believe that this overlap requirement will
just magically vanish or be significantly reduced if they migrate off
COBOL to any of the existing alternatives or if they migrate to a
different platform, they are in for a unpleasant surprise.
I believe that we should modernize the software development using COBOL
in a smooth way by providing the COBOL developer with "modern" libraries
and tools that make some tasks easier while maintaining the spirit and the
strengths of COBOL.
I did the same thing for our "legacy" PL/1 environment, and I will try
to give
you an example.
If you use in-storage tables in COBOL or PL/1 programs (for example tables
of keys to lookup while processing a database or file sequentially), you
normally
use in those "old" languages a table with fixed limits, so you have to
do an estimation,
how large this table could get; maybe you read the table from a file at
the beginning
of the processing, and the number of entries is varying.
I use a library instead, which puts the keys in a weighted tree (AVL
tree) and allows
the PL/1 or COBOL program to search very fast for the existence of the
key in
this AVL tree. There is virtually no limit to the number of entries; the
AVL tree
resides in dynamic storage. There is no problem, if there are 1000, 10000 or
even a million keys (which is far from realistic numbers). The coding
for the
COBOL user is very simple and straightforward; he or she only has to take
care that the tree (as a whole) is freed when it is no longer needed (by
a simple
call, again).
This is what the C++ and Java guys do all the time ... I don't like
their languages much,
but I do like the concepts and how easy they can be used. And the programs
are really fast, if the libraries are implemented in the right way. So I
think we should
provide our COBOL and PL/1 programmers with the right solutions, to
enable them
to bring new life to old or new COBOL and PL/1 applications.
Another similar topic is: enable PL/1 and COBOL programs to do XML parsing
and writing of XML documents in an easy and efficient way. I have some
problems
with the performance implications of XML processing, too; but when
communicating
with external partners, it is a necessity, and so you have to cope with
it. The existing
solutions in the market work well with C++ and Java, but not so well
with PL/1 and
COBOL. I have solutions for this problem, too.
If you want to know more about my efforts to modernize COBOL and PL/1
development, please contact me offline.
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
