Re: What's really wrong with COBOL?

Re: What's really wrong with COBOL?

[William Thomas Wolfe, 2847]

From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss):
> All these recent jokes about COBOL's age and verbosity are fun, but, if
> we can get serious for just a sec. or two...
> 
> What are the real SUBSTANTIVE problems with COBOL?  Suppose I were suddenly in
> charge of a large DP shop.  Would it make sense for me to migrate away from
> COBOL?  Remember that my DP shop has billions of lines of installed code in
> COBOL, and conversion will require enormous time and cost.  Not to mention
> exposing me to the risk of problems when installing new softwares.
> 
> Now, I'm a reasonably hi-tech guy, not long out of Engineering school, but
> I need real arguments (that make business sense) to give to my boss, the CEO.
> And, are there viable alternatives such as "re-engineering" the existing code
> and investing in tools that make the COBOL environment more palatable?

   From a business perspective, the real substantive problem with COBOL
   is that typically 80% of effort is spent trying to maintain code which
   fundamentally is unmaintainable.  The reason for this is that COBOL has
   found itself unable to evolve quickly enough to keep up with the last
   20-30 years' worth of evolution in programming language technology.

   The language COBOL was invented by the US Department of Defense, and
   later abandoned because it was no longer adequate as a tool for the
   effective support of good software engineering practices.  Since the
   DoD also has had a large installed base of COBOL software, it has been
   the leader in applying effective strategies for dealing with that
   particular problem.

   The Ada programming language was designed with a mechanism called
   "pragma Interface" which enables it to call code written in other
   languages.  If you have one of the compilers which supports calls
   to COBOL (the IBM Ada compiler should certainly be able to do this),
   you can simply call upon your existing COBOL software system for as
   long as it remains serviceable.  Ultimately, old COBOL systems become
   so unmaintainable that it makes sense to rewrite the system, and at
   that point the system should be rewritten in Ada.  So the conversion
   need not be done all at once (although there are a number of companies
   which will gladly do such a conversion for you, for enough $$$); by 
   simply using Ada for all NEW code, it is possible to upgrade to Ada 
   incrementally without too much stress on the organization.

   Now let me just briefly sketch out why COBOL is considered to be no
   longer adequate.  In Ada there is a concept of separating specification
   from implementation.  You can design a software system in terms of 
   different subsystems by specifying (in a "package specification") how
   each of the subsystems is to function.  Then you compile these into
   the Ada program library.  Now there is an agreement among the members
   of the software development team that this is what the different 
   subsystems will do, and all that remains is to write the software 
   which will cause the subsystems to do what is expected of them.  What
   has happened is: we have broken down a large problem into several
   smaller subproblems.  Now the project can be broken up into several
   different programming teams, NONE OF WHICH KNOWS ANYTHING ABOUT HOW
   ANY OF THE OTHER SUBSYSTEMS ARE ACTUALLY IMPLEMENTED.  It is enough
   that they understand how the other subsystems are to operate.  They
   can then write their particular subsystem relying only on the services
   which the other subsystems have agreed to provide -- the specification
   of their subsystem is a "contract" that they must fulfill, and in turn
   the other teams must fulfill their contracts.  The Ada compiler will
   ensure that the terms of the contract are adhered to.  

   So why is this going to help us in maintenance?  Well, let's assume
   that a change is needed.  Unless it's a truly major change which would
   basically invalidate the entire system, we can almost always limit the
   scope of the change to a particular subsystem.  If that subsystem is
   in turn partitioned into different sub-subsystems, the change can be
   limited even further.  Only the changed area will have to be recompiled,
   and soon the modified system is up and running.  But what if there has
   to be a change in the terms of a contract?  Now the Ada compiler REALLY
   helps you out... it will automatically identify parts of the software
   system which depended upon the old contract but which are no longer
   being satisfied due to the changes which were made.  It helps you to
   minimize the extent of any needed changes, and helps you to track and
   control the effects of any major change.  But more than this -- think
   about the potential for reusing subsystems.  Once you have a very useful
   subsystem written and tested, you can use it over and over again without
   any copying of code.  With copying of code there is the problem of trying
   to find all the copies to update them in case there is a change, but in
   Ada there is no need.  If you find a defect in the implementation of a 
   subsystem, you can simply correct the implementation and let the Ada 
   compiler handle the rest.  And there is even the ability to construct
   "generic" subsystems -- subsystems which are written to do something
   generally and which (with you supplying a small amount of information)  
   can be quickly customized to do it in a particular fashion.  For one
   example, suppose that you wanted to have a priority queue (a system
   in which items are deposited with different priorities, and you always
   want to retrieve the item which has the minimum or maximum priority).
   In Ada, you can write a package Generic_Priority_Queue in which the
   idea of a priority queue is programmed, without knowing exactly what
   type of object is to be carried in the queue (the user will decide this).
   Later, the user comes along, describes the type of object to be carried,
   and all that software for handling a priority queue is immediately made
   available for use with that type of object, courtesy of your Ada compiler.
   You could also describe a network and how to do things with it (compute
   the shortest path between two points, find out how many connections will
   have to break in order to cut off all paths between two given points, etc.)
   independently of the type of object at each point or the nature of the 
   connections.  As you can see, this is a very powerful mechanism for reuse.

   This article is long enough already, but if you pick up a book on the
   Ada programming language and study it, you will begin to realize just
   how much advancement has occurred over the last 20-30 years, and how
   COBOL has not kept up with the times.  Please contact me via electronic
   mail (the address is wtwolfe@hubcap.clemson.edu) if there is anything
   I can provide (such as hard numbers on exactly how much Ada has been
   demonstrated to improve productivity) which would fall outside of the
   intended scope of the alt.cobol newsgroup.  As a specialist in Business
   Information Systems who has chosen Ada as the preferred technology for
   that domain, I will be happy to provide assistance to anyone who would
   like more information on why I believe this is far and away the best 
   language technology for the domain of Information Systems applications.
   

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: What's really wrong with COBOL?

[Jeffrey Weiss]

In article <8458@hubcap.clemson.edu>,
 billwolf exercises the keyboard and comes up with:

>From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss):
>> 
>> ...What are the real SUBSTANTIVE problems with COBOL?
>
>   From a business perspective, the real substantive problem with COBOL
>   is that typically 80% of effort is spent trying to maintain code which
>   fundamentally is unmaintainable.  The reason for this is that COBOL has
>   found itself unable to evolve quickly enough to keep up with the last
>   20-30 years' worth of evolution in programming language technology.
>
[   ...history of COBOL and Software Engineering 101 deleted...]

>   Now let me just briefly sketch out why COBOL is considered to be no
>   longer adequate.

[   ...brief 80-line description of Ada features deleted...]

Those lines indicated two features (apparantly well supported by Ada) that
might be linked to maintainability.  Those are:
	- Module dependency tracking to aid in identifying "ripple-effects"
	  when implementing a change.
	- Ability to build callable libraries of generic functionality, thus
	  supporting layered, modular programming.

I agree, these are important.  (Someone else has mentioned local variables not
existing in COBOL, a feature which fits nicely in the above list.)  Now, are 
there really no ways to implement the above features in a COBOL environment?
Are function calls and libraries not possible for some reason?  And could
tools such as SCCS or "make" provide the first point?

...mit-eddie!mck-csc!jw
Jeffrey Weiss

Re: What's really wrong with COBOL?

[William Thomas Wolfe, 2847]

From article <423@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss):
>>   typically 80% of effort is spent trying to maintain code which
>>   fundamentally is unmaintainable.  The reason for this is that COBOL has
>>   found itself unable to evolve quickly enough to keep up with the last
>>   20-30 years' worth of evolution in programming language technology.
> 
% 	- Module dependency tracking to aid in identifying "ripple-effects"
% 	  when implementing a change.
% 	- Ability to build callable libraries of generic functionality, thus
% 	  supporting layered, modular programming.
% 
% I agree, these are important.  (Someone else has mentioned local variables not
% existing in COBOL, a feature which fits nicely in the above list.)  Now, are 
% there really no ways to implement the above features in a COBOL environment?
% Are function calls and libraries not possible for some reason?  And could
% tools such as SCCS or "make" provide the first point?

   There's considerably more as well... Ada's exception handling (a means
   of "damage control", similar to COBOL's "ON END" but considerably more
   sophisticated) and many other safety features enhance the reliability 
   of software systems in ways that simply cannot be attained within COBOL.

   There is also multitasking -- the ability to express the idea of 
   objects which do their work in parallel.  Here COBOL is helpless,
   even though it is much more natural in many cases to break down a
   system into different objects which exist in parallel and interact
   with one another.  

   And remember the generic priority queue I described earlier?  If one
   is to design such a system so that it can hold any number of objects,
   it is necessary to implement it using what is known as "recursion". 
   This is what happens when a procedure or function calls itself, an
   idea which COBOL strictly prohibits.  Recursion is considered to be
   fundamental to the proper implementation of many such data structures,
   and in fact is a fundamental basis of much of Computer Science.

   There is also tremendous difficulty when one tries to describe what
   is known as an "abstract data type" in COBOL.  This is a style by
   which one identifies and characterizes a real-world object through
   a description of the operations which can be done with that object,
   such that a guarantee exists that nobody can do anything with the
   object without making use of the predefined operations available 
   for it -- this makes sure that the "integrity of the abstraction",
   or the standard concept that everyone has of the object, is upheld.
   In COBOL, even the idea of having user-defined types is not supported,
   much less supported with the level of enforcement provided by the
   Ada "limited private" mechanism.

   There is quite a lot that COBOL has missed out on over the years,
   and this is why the DoD has given up on the idea of continuing to 
   use it.  With Ada support available now for typical MIS platforms, 
   and given the prospect of an incremental conversion, it just doesn't 
   make much sense to continue on with COBOL. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: What's really wrong with COBOL?

[jim frost]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) babbles:
>   There is also multitasking -- the ability to express the idea of 
>   objects which do their work in parallel.
[...]
>   it is necessary to implement it using what is known as "recursion". 
>   This is what happens when a procedure or function calls itself
[...]
>   ...an "abstract data type" ... is a style by
>   which one identifies and characterizes a real-world object through
>   a description of the operations which can be done with that object,

What is this, a review of a freshman course in CS?  Have you resorted
to believing that all people who use cobol are "common folk, people of
the land (you know, morons)"?

Assume, for a change, that we're all professionals here and don't need
trivial concepts described, especially inaccurately.

jim frost
saber software
jimf@saber.com

Re: What's really wrong with COBOL?

[William Thomas Wolfe, 2847]

From madd@world.std.com (jim frost):
> What is this, a review of a freshman course in CS?  Have you resorted
> to believing that all people who use cobol are "common folk, people of
> the land (you know, morons)"?

   At my undergraduate institution, those who opted for the CIS program
   (Computer Information Systems) rather than the CS program (Computer
   Science) did not receive instruction regarding topics such as ADTs,
   recursion, and so on, receiving instead extensive COBOL and database
   knowledge without benefit of a solid computer science foundation.

   This was at Purdue University, the first institution in the world
   to institute a computer science program... the pattern seems to have 
   been characteristic of CIS programs at that point in time.

> Assume, for a change, that we're all professionals here and don't need
> trivial concepts described, especially inaccurately.

   Please explicitly point out what specific statements you considered
   inaccurate, if any.  The fact that many CIS degrees do not provide
   their holders with adequate preparation for the task of keeping up
   with technical advances in computer science does NOT imply any 
   lack of professionalism on the part of the degree-holder, at least
   from my point of view.  Your view, of course, may be different.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: What's really wrong with COBOL?

[jim frost]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas
Wolfe, 2847) writes:

>   Please explicitly point out what specific statements you considered
>   inaccurate, if any.

Earlier he had written:

>  There is also tremendous difficulty when one tries to describe what
>  is known as an "abstract data type" in COBOL.  This is a style by
>  which one identifies and characterizes a real-world object through
>  a description of the operations which can be done with that object,
>  such that a guarantee exists that nobody can do anything with the
>  object without making use of the predefined operations available 
>  for it

You are defining "abstract data type" incorrectly; I would call it
"any data type which does not exist by default in the language
specification".  What you are describing is a little more complex than
an abstract data type, yes?

Happy hacking,

jim frost
saber software
jimf@saber.com

Re: What's really wrong with COBOL?

[a.lawrence]

From article <8483@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ):
> From madd@world.std.com (jim frost):
>> What is this, a review of a freshman course in CS?  Have you resorted
>> to believing that all people who use cobol are "common folk, people of
>> the land (you know, morons)"?
> 
>    At my undergraduate institution, those who opted for the CIS program
>    (Computer Information Systems) rather than the CS program (Computer
>    Science) did not receive instruction regarding topics such as ADTs,
>    recursion, and so on, receiving instead extensive COBOL and database
>    knowledge without benefit of a solid computer science foundation.
> 
>    This was at Purdue University, the first institution in the world
>    to institute a computer science program... the pattern seems to have 
>    been characteristic of CIS programs at that point in time.
> 

I don't know when you did your studies in Computer Science, but I did
mine in the late 60's at the U. of Waterloo.  COBOL was never mentionned
once in the curriculum at the time and databases were still the subject
of much research and very little practicle experience.  I did recieve
a fairly good *basic* training in compiler theory, numerical methods,
basic operating systems concepts, and hardware theory.

>> Assume, for a change, that we're all professionals here and don't need
>> trivial concepts described, especially inaccurately.
> 
>    Please explicitly point out what specific statements you considered
>    inaccurate, if any.  The fact that many CIS degrees do not provide
>    their holders with adequate preparation for the task of keeping up
>    with technical advances in computer science does NOT imply any 
>    lack of professionalism on the part of the degree-holder, at least
>    from my point of view.  Your view, of course, may be different.
> 

Keeping up with the technical advances in information science is a matter
of professionalism, not basic education.  In the *REAL* world, there is
no need for the average programmer to be a "Software Engineer".  In fact,
based on over 20 years of experience, I find that perhaps 1 programmer/
analyst out of 10 in a large installation (over 100 programmer/analysts)
could even be remotely classified as a "Software Engineer"; and those
I would classify as "Software Engineers" have the strangest educational
backgrounds from high-school drop outs to PhD's in Nuclear Physics.

You may dislike COBOL, but for large _business_ systems I wouldn't use
any other language.  I can put multiple programmers to work on the same
program (I have had as many as 10 work on the same program at the same
time). The programmer who "tests/debugs" a module does not have to be the
programmer who wrote it.  Without any code generation tools I can expect
an average though put of approx. 100 line of code per man day, including
design and testing time.  The code will be portable without any special
hooks (i.e. conditional compilation lines) to any machine with a ANSI
COBOL compiler.  My programmer's won't waste time chasing bugs cased
by pointers being misused, writing special file access routines, or trying
to write their "own" function for string manipulation.

Most of what you have described in previous posts as the qualities of ADA
and deficiencies of COBOL are not a properties of the actual language being
used, but rather of the analysis and design tools being used.  No computer
language is going to make future maintenance and enhancement easier if 
proper thought is not put into the design before the first line of code
is written.  While object oriented techniques provide many advantages, there
is also a price to pay in code size and especially performance.  

---
On a clear disk you can seek forever.
-------------------------------------------------------------------------
Andrew Lawrence        |  alawrenc@sobmips.sobeco.UUCP
Informaticien Conseil  |  {attcan,mcgill-vision}!sobeco!sobmips!alawrenc
3462 Jeanne-Mance, #1  |
Montreal, Que  CANADA  |  Voice (514) 281-5196

Re: What's really wrong with COBOL?

[Mike Feldman]

Truce! PLEASE.......?
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
+1-202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: What's really wrong with COBOL?

[Steve Bridges]

In article <1990Mar24.154331.3328@world.std.com> madd@world.std.com (jim frost) writes:
>billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) babbles:
>>   There is also multitasking -- the ability to express the idea of 
>>   objects which do their work in parallel.
>[...]
>>   it is necessary to implement it using what is known as "recursion". 
>>   This is what happens when a procedure or function calls itself
>[...]
>>   ...an "abstract data type" ... is a style by
>>   which one identifies and characterizes a real-world object through
>>   a description of the operations which can be done with that object,
>
>What is this, a review of a freshman course in CS?  Have you resorted
>to believing that all people who use cobol are "common folk, people of
>the land (you know, morons)"?
>
>Assume, for a change, that we're all professionals here and don't need
>trivial concepts described, especially inaccurately.

Jim is right -- this does sound like a freshman CS course (a whole lot
like a one I took).

Let's face facts -- there is nothing inherently wrong with COBOL.  A
properly structured COBOL program CAN have a modular design, can
do recursion (see the following code segment:


	PROCEDURE DIVISION.
	     MAIN-PARA.
		MOVE "N" TO PARA-STOP.
		PERFORM PARA-A THRU PARA-A-EXIT.
		STOP RUN.

	     PARA-A.
		do something here.
		PERFORM PARA-A THRU PARA-A-EXIT UNTIL PARA-STOP
	                = "Y".
	     PARA-E-EXIT.

If you dissect that code, it is recursive.  The initial call in the
main paragraph will execute ONCE.  The second perform within
PARA-A will continue to perform PARA-A UNTIL THE EXIT CONDITION
IS MET!.

Granted, COBOL was designed a long time ago, but it is still a
valid language, and possibly more portable than C.  COBOL exists
for all the operating systems I am familiar with (Unix, MS/PC-DOS, CP/M,
MVS, VMS, VRX, ITX, IRX, IMOS.....).

You can take that same COBOL code, re-compile it on the target machine,
and IMHO, probably spend less time getting it to work than trying to
take a C program with it's dependence on include files.

Don't get me wrong,  C is great for some things, but let's remember
why COBOL was developed...  for businesses.  Not to write operating
systems in, or word processing applications, or other similiar
types of things where you have to get down and talk to the hardware
at a lower level than COBOL (or FORTRAN) will allow.

In our department, we use COBOL on a daily basis.  Why?  Because
development time is quicker, debugging is easy, file I/O is quick,
and it runs like a scalded cat.

But, we also use 4 G/L type products like Informix and Progress.  Why
don't we use Pascal/C, or other object oriented type stuff?  Because
IT DOESN'T MEET OUR NEEDS.  We need to analyze business information,
not spend time worrying about abstract data types and whether our
product can do recursion.  

Granted, if we were responsible for writing operation systems and the
like, OO type languages would be the choice, but we don't.

Bill - 
I guess what I am trying to say is don't condemn a language that people
use until you look at what the problems they are trying to solve.



	

-- 
Steve Bridges                    | NCR - USG Product Marketing and Support OLS
Steve.Bridges@Dayton.NCR.COM     | Phone:(513)-445-4182 622-4182 (Voice Plus)
..!ncrlnk!usglnk!uspm650!steve   | AOPA #916233
..!uunet!ncrlnk!usglnk!uspm650!steve| PP-ASEL, AMEL

Re: What's really wrong with COBOL?

[Mike Harrison]

In article <8458@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss):
>> All these recent jokes about COBOL's age and verbosity are fun, but, if
>> we can get serious for just a sec. or two...
  ...
>
>   Now let me just briefly sketch out why COBOL is considered to be no
>   longer adequate.  In Ada there is a concept of separating specification
>   from implementation.  You can design a software system in terms of 
>   different subsystems by specifying (in a "package specification") how
>   each of the subsystems is to function.  Then you compile these into
>   the Ada program library.  Now there is an agreement among the members
>   of the software development team that this is what the different 
>   subsystems will do, and all that remains is to write the software 
>   which will cause the subsystems to do what is expected of them.  What
>   has happened is: we have broken down a large problem into several
>   smaller subproblems.  Now the project can be broken up into several
>   different programming teams, NONE OF WHICH KNOWS ANYTHING ABOUT HOW
>   ANY OF THE OTHER SUBSYSTEMS ARE ACTUALLY IMPLEMENTED.  It is enough
>   that they understand how the other subsystems are to operate.  They
>   can then write their particular subsystem relying only on the services
>   which the other subsystems have agreed to provide -- the specification
>   of their subsystem is a "contract" that they must fulfill, and in turn
>   the other teams must fulfill their contracts.  The Ada compiler will
>   ensure that the terms of the contract are adhered to.  

First let me say that I am an enthusiastic supporter of Ada's separate
compilation mechanism and the separation of specification and implementation.
I believe that those mechanisms, together with private types and packages are
*well* worth the (occasional) infelicities of Ada.
[I particularly miss the 'everything is an expression' character of Algol 68!]

However, let's not get carried away by all this.

Yes, the Ada specifications do provide a sort of interface contract, but they 
only enforce the *syntactic* (and perhaps *static* semantic) aspects of the 
interface, for example, for subprograms:

    - number and order of parameters,

    - types of parameters,

    - modes of parameters,

    - types of results.

There is however, no support for checking the *dynamic* semantics of the 
interface, so the programmers on opposite sides of the interface may take very
different views of the *meaning* of so data or code object, eg. a parameter may
describe a 'length'; the specification writer may view this as 'feet', the
writer of the body may treat the value as 'inches' and some user may be expecting
'metres'.
This is usually handled by an associated 'specification document', (I know that
complicated data type definitions can be written to ameliorate this example,
but that still can't prevent a programmer from multiplying by 12 to convert from
'feet' to 'inches').

I am not saying that Ada should have included mechanisms to control this sort
of problem, it was a considerable advance of previous languages, but I think 
that we should not try to *oversell* Ada.

There is probably a case for putting some kind of assertion mechanism (at least
on interfaces) into the new Ada design.
I know about the problems of dynamic assertions, what I mean is some sort of
statically evaluable assertions, to be used as an extension of the present
separate compilation checks.

Has anybody done any work on this?

Mike,



Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;

Re: What's really wrong with COBOL?

[William Thomas Wolfe, 2847]

From mph@lion.inmos.co.uk (Mike Harrison):
> Yes, the Ada specifications do provide a sort of interface contract, 
> but they only enforce the *syntactic* (and perhaps *static* semantic) 
> aspects of the interface...  There is however, no support for checking 
> the *dynamic* semantics of the interface...

   To completely check the semantics of the interface is probably so
   computationally complex as to be not realistically achievable.  But
   practically speaking there is a way to let Ada help you here as well.

   Simply temporarily *remove* the modified procedure or function from
   the specification and recompile.  Then the Ada compiler will point out
   *all* places at which the modified procedure or function was referenced.

   Now recompile the "complete" specification, and verify that all the 
   points at which the semantically modified procedure or function was 
   referenced are OK with respect to the semantic modification.  This
   has the disadvantage of perhaps being overconservative -- leading you
   to points at which the semantic change may not actually do any harm --
   but it's certainly better than manually trying to track the effects of
   the change, and in all probability it's the most practical solution.
    

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Re: What's really wrong with COBOL?

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / alawrenc@sobeco.com (a.lawrence) / 10:21 pm  Mar 27, 1990 /

>You may dislike COBOL, but for large _business_ systems I wouldn't use
>any other language.  I can put multiple programmers to work on the same
>program (I have had as many as 10 work on the same program at the same
>time). The programmer who "tests/debugs" a module does not have to be the
>programmer who wrote it.  Without any code generation tools I can expect
>an average though put of approx. 100 line of code per man day, including
>design and testing time.  The code will be portable without any special
>hooks (i.e. conditional compilation lines) to any machine with a ANSI
>COBOL compiler.  My programmer's won't waste time chasing bugs cased
>by pointers being misused, writing special file access routines, or trying
>to write their "own" function for string manipulation.

I've  been a consultant  on HP3000's  running MPE were COBOL V/PLUS (screen
package) and   IMAGE (DBMS) are the norm    for 10 year   so  I  speak from
experience when I say I have seen the worst code and most of it  is written
in COBOL.  This is not to say that you  *have*  to write bad code in COBOL.
Indeed I have seen good code in COBOL too.  In keeping with the theory that
each language is a tool that has  value and can be  applied to a problem at
hand, COBOL is  also a  tool that  has value can  is useful.

What's wrong with COBOL is that it hasn't kept  pace.  In  the COBOL that I
used to use there was no  support for  floating point numbers, pointers and
bit fields.   These are simply limitations  of the language and they  cause
programmers problems  that  must be gotten  around.    By  saying that your
programmers "won't waste  time chasing bugs cased  (sic) by  pointers being
misused"  you are  also saying   that your programmers won't  use pointers.
Pointers  are  very  useful.    You're COBOL  compiler  uses  them but  you
programmers  can't.   So when they  are faced with  a problem that pointers
would easily and cleanly solve, they can't use them and  are forced to come
up with another,  often uglier and  slower,  solution.  Are you saying that
floating point numbers or bit fields are not  useful!  Well other languages
use these things and if you're interfacing to them you have problems.

Another thing  about COBOL that I  could never  understand is the  lack  of
understanding of  the  language itself by  the  people that  use  it.   For
example,  COBOL  programmers are inhertantly bad  at defining  dates.  I'll
often see 10-20 definitions for CURRENT-DATE and  tons of  useless  move of
data from a PIC 9 field to a PIC X field so that the programmer can  say IF
CURR_MM_X = "10" instead of IF CURR_MM_9 = 10.   To me this  is just a lack
of understanding  of the  language itself.  I'll eliminate the  extra dates
and use only 2 or 3 (MDY, YMD) and the program will work like a champ.

I also can't tell you how  many times  I have seen  terrible abuses of I/O.
Programmers who CLOSE AND RE-OPEN FILES JUST TO REWIND THEM! or OPEN a file
write a record  CLOSE the file  only to perform the OPEN-WRITE-CLOSE  again
and again for thousands of records only because they're too lazy to code it
to keep the file open.

Besides not  keeping  pace,  COBOL  seems to   get   all those MBA  degreed
"wanna-be" programmers  which gives COBOL a  bad rap and keeps  the  coding
sytle at a minimal.