In the Unix/Linux environment (which is the scope of this discussion), COBOL is a very rare bird -- almost universally...
unknown. C is the dominant programming language, and the semantics of the C programming language are almost universal throughout the OS and application development environment. Both languages support structured records in RAM and on disk, and structured, modular logic -- and a full C development environment is already present in every Linux system at no extra cost, so it's no more difficult for a competent programmer to write a business application in C than it is to write the same application in COBOL. Good program logic and data structure design are necessary for both languages; it's only a discussion of how the logic and data structures are expressed. It's interesting that one of the best business programming books I've ever seen has all the examples implemented entirely in GW-BASIC...8-).
All the COBOL compilers and tools available on Linux (specifically on zSeries and on Linux in general) are commercial applications. They are *very* expensive to acquire, and are difficult to integrate -- special libraries, different runtime requirements, non-standard calling conventions, etc. So, while I don't have any objections to COBOL per se (I've written a few zillion lines of the stuff myself), it's simply not present in most Linux environments, and the cost of supporting COBOL applications in the Linux environment is prohibitive compared to supporting the same application written in C, both from a configuration/operations perspective, and from a tooling acquisition perspective.
The point I was making: for Linux, supporting COBOL on Linux is most likely to be a transition strategy; it is highly unlikely to be the final destination.
If someone feels like finishing the GNU COBOL compiler project and gets it incorporated into the distributions, my opinion might change. Until then, COBOL is simply unlikely to make any headway in the Linux environment.
Why would you use 'C' instead of COBOL to produce reports?
It costs nothing additional to develop and use C applications on Linux, and the entire environment is oriented toward supporting C applications in an efficient and natural manner. It costs a substantial amount to support COBOL on Linux. See above for discussion of language features, etc. Nothing in the Linux environment *prevents* use of COBOL; the observation is that COBOL is rarely selected in that environment for purely economic reasons.
Wrt to reports, in the Linux world, it would be much more likely that report programs would be written in Perl or Python than C. Both have sophisticated text manipulation capabilities not easily implemented in C or COBOL, and (at least in the case of Perl), there is a enormous library of functions available for any concievable need that are available for public re-use with no license attached. Taking advantage of these freely-available modules makes the case for developing a compiled application in either C or COBOL suspect -- it's just way too much easier to write applications like that in Perl. Perl's interface to SQL-based DBMS systems is also almost trivial to use (much simpler than either the C or COBOL model), and as these COBOL reporting applications typically also move the data to some kind of DBMS, that's further argument for making it happen with Perl instead of compiled stuff.
It's not a discussion about whether C is better than COBOL. It's a business decision that in a Linux environment, I can get more working applications per hour for less expensive resources and requirements from C or Perl than COBOL. Given that, most organizations choose C or Perl over COBOL for new development on Linux.
Dig Deeper on IBM system z and mainframe systems
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.