Learning COBOL Without Access to Mainframe

Question

I am a graduate student majoring in Computer Science. My department teaches the majority of its courses using Java (though I did take one course on system architecture that used C to demonstrate processor scheduling, memory management, etc....but I digress).

I want to learn more about COBOL, but I don't have access to a mainframe system. Can anyone please recommend a free COBOL compiler for Windows that would enable me to get through some basic COBOL tutorials?

Disclaimer: yes, I've Googled this already, so hoping for some experienced individuals to give some further info.

Thanks!

Answer 1

Other posters have suggested Tiny COBOL, but have a look at OpenCOBOL too. OpenCOBOL is a cross compiler to C and has a fairly active development community.

COBOL is not a difficult language to learn. Unless you are tying to work your way into a mainframe shop, spending a lot of time studying COBOL may not have much career payback.

As belisarius pointed out, it is not the language as much as the environment that needs to be learned. By analogy, there isn't very much to learn about the C language either. However, just knowing C will not get you very far - you need to work with the huge standard library that comes with it. COBOL is similar in that respect. The difference is that COBOL does not come with a huge standard library, it is part of a package that often includes: CICS, DB/2, MQ-Series and an array of other library services (LE Services in an IBM environment).

COBOL can be found outside of a mainframe environment but the mainframe is its "real home". As a generalization, "mainframe" implies an IBM mainframe running Z/OS (many may take exception to this statement). This publication: Introduction to the Mainframe - z/OS is a good place to get a feel for what an IBM mainframe environment is like.

The things I find characterize COBOL are:

• COBOL is a procedural language. Some vendors have added OO extensions and new COBOL language standards include OO extensions, but this is largely window dressing. COBOL is fundamentally a procedural language.

• Data declaration. The PICTURE/USAGE thing is a bit of a mind bender. Data declaration combines internal data representation (binary, packed decimal, floating point, character, etc.) with presentation (number of digits, leading zeros, sign, etc.) into a single declaration.

• REDEFINES used to provide different views of the same underlying memory.

• Hierarchical data declarations. Data hierarchy is defined using level numbers. Level 1 defines the top of the hierarchy and increasing numbers define lower levels. Levels 66 (in conjunction with RENAMES), 77, 88 have special meanings.

• Flow of control. Many programmers (even some veteran COBOL programmers) view SECTION/PARAGRAPH in a manner similar to a procedure call. They are completely different. SECTION/PARAGRAPH do not follow normal stack oriented call/return semantics. COBOL uses a unique mechanism to manage return from PERFORMed sections/paragraphs.

• Monolithic programs with tons of global variables. It is not uncommon to find COBOL source files running into thousands of lines with several hundred global variables. COBOL doesn't have to be written this way - I believe this is a legacy dating back to a time when procedure calls were considered costly but PERFORMing a SECTION/PARAGRAPH was very efficient. The habit seems to have stuck and newer COBOL programs tend to be written as monolithic monsters too.

• String handling nightmare. COBOL does financial calculations very well. It does not do string handling very well at all. The string handling verbs INSPECT, STRING and UNSTRING can do a number of interesting things, but manage to be quite aggravating too.

• COPY/REPLACING and REPLACE compiler directives need to be understood. They behave somewhat differently than file inclusion in most other languages. Most shops use COPY only for common record or data declaration, others use them for common procedural code too (with REPLACING and or REPLACE).

Given a working knowledge of C, you should be able to pick up on COBOL without much difficulty.