home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / cobol / 353 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  4.9 KB
  1. Path: sparky!uunet!usc!cs.utexas.edu!rutgers!igor.rutgers.edu!romulus.rutgers.edu!morrow
  2. From: morrow@romulus.rutgers.edu (John Morrow)
  3. Newsgroups: alt.cobol
  4. Subject: Re: The future of COBOL?!?!
  5. Message-ID: <Jul.30.21.06.59.1992.1772@romulus.rutgers.edu>
  6. Date: 31 Jul 92 01:06:59 GMT
  7. References: <1992Jul30.022405.8953@uwm.edu>
  8. Organization: Rutgers Univ., New Brunswick, N.J.
  9. Lines: 89
  10.  
  11. rca@csd4.csd.uwm.edu (Robert C Allender) writes:
  12.  
  13. >After reading one of the responses to "The Inevitable Question" I was
  14. >compelled to ask this of the COBOL programmers in the world:
  15.  
  16. >      The C language has caused a bigger uproar in the past few years than
  17. >      Pascal did way back when.  Now there's the object-oriented C++ that
  18. >      uses classes and promotes encapsulation and polymorphism.  Since a big 
  19. >      problem with COBOL maintenance seems to be the endless patching of
  20. >      endless patches in old code,  What do you think about these proposed
  21. >      solutions that C++ supposedly offers?  
  22.  
  23. I, personally, do not think C or C++ will ever replace COBOL in one of 
  24. the primary areas in which COBOL is used -- primarily business programming.
  25. If COBOL DOES wind up getting replaced in this area, it will probably be
  26. by a forth generation language or something like Natural that "looks like"
  27. COBOL.
  28.  
  29. There are several very important reasons for this.
  30.  
  31. 1) The sheer volume of existing COBOL programs linked with the current
  32.    "lean and mean" approach that businesses have been taking make it
  33.    unlikely that many businesses will be able to afford a major redesign
  34.    of an existing system in the near future.
  35.  
  36. 2) Many existing systems work very well.  There is even less reason to
  37.    replace a system that works.  Remember, the people that often make this
  38.    sort of decision are management, not programmers or analysts.  When
  39.    programmers and analysts DO have input, see (5) below.
  40.  
  41. 3) Many of the applications written in COBOL don't really need the
  42.    features of a "data structures" language like C.  Bit level management
  43.    is not necessary for most accounting and record keeping functions.
  44.    Many "data structure" type functions also can be performed outside of
  45.    COBOL programs using either sort utilities or a pre-existing database
  46.    interface such as VSAM, Adabas, or DB2.
  47.  
  48. 4) Many of the programmers who write in COBOL are not "computer scientists".
  49.    They know no language other than COBOL and would have trouble adapting
  50.    to a "scientific" looking language such as "C".  Companies filled with
  51.    programmers hired to program in COBOL would have trouble training large
  52.    numbers of people in an entirely new system.  Firing large numbers of
  53.    people and hiring new ones is not only difficult but has a severe
  54.    impact of moralle and causes the loss of large amounts of experience.
  55.  
  56. 5) Due to (4), many people who were hired to, say, run a mainframe or
  57.    program in COBOL have a vested interest in making sure the company
  58.    CONTINUES to do things as usual.  Upgrades are one thing but new systems
  59.    are another.  The Wall Street Journal had an article on this a few years
  60.    ago to the effect than many MIS departments resist using micro-computers
  61.    because they are mainframe people and it would put them out of work.
  62.  
  63. 6) COBOL, in my opinion, is MUCH easier to maintain than C.  If I hand
  64.    you a standard C program and a standard COBOL program that does the
  65.    same thing, written by someone you don't know, I bet you could more 
  66.    easily figure out what the COBOL program is doing, PERHAPS EVEN IF 
  67.    YOU DON'T KNOW COBOL.  (I am willing to discuss this point if you want).
  68.  
  69. 7) The same COBOL code you wrote 20 years ago can always be brought back
  70.    in if you need it.  If you toss COBOL and go with C or C++, you could have
  71.    problems.
  72.  
  73. 8) Many of the existing files/datasets used by companies presently using
  74.    COBOL are formatted with COBOL working storage and file I/O in mind.
  75.    Changing languages could require large amounts of data reorganization.
  76.  
  77. 9) COBOL is probably more forgiving than C and easier to debug.  I assume
  78.    similar statements could be made about C++ but I may be wrong.
  79.  
  80. In general, the above issues might not be a factor for a small company
  81. with a few hundred records, a few dozen programs, and three good
  82. programmers.  But when you get into large corperations with hundreds
  83. of employees, thousands of programs, and millions of records, it
  84. becomes more of a problem.  I have little doubt that COBOL will be
  85. around for decades -- perhaps as COBOL 99 with new features such as
  86. recursion and pointers -- but with COBOL syntax none-the-less.  Companies
  87. have invested too much in it to drop it, expecially if their current 
  88. system works which it usually does.
  89.  
  90. >I'm certain that this will be an interesting debate!  
  91.  
  92. I look forward to seeing what others have to say.
  93.  
  94. John Morrow
  95. morrow@remus.rutgers.edu
  96.  
  97. PS - And remember -- we are mutants here.  Many COBOL programmers work
  98.      on IBM MVS/OS machines with no net access.  Academia does not 
  99.      necessarily represent the real world.
  100.