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!

Solution 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.

Solution 2

I'll not address your specific question, since it was many years ago that I stopped working as a mainframe systems programmer (and with mainframes in general ... and that includes COBOL). Nevertheless, there are two points that I want to emphasize:

1. COBOL is an easy to learn language. You'll feel at first that the syntax is daunting. A lot of "divisions", "sections" , "paragraphs" ... just try to understand why they exist. Nobody writes those labels. The way COBOL uses and redefines data structures is perhaps the most interesting concept, try to understand it well.

2. This is the key point. I said "COBOL is easy". Now the bad news: being a fair mainframe COBOL programmer is NOT easy. But that has nothing to do with COBOL, it's the environment. The mainframe is big, and there are a lot of "ecosystems" in there. You have DB2, CICS, some JCL, and VSAM as a bare minimum, and perhaps a dozen more, depending on your installation. Printers, tapes and other specialized and hard to manage hardware too. Each one of them requires several years to tame, and that's the real value of a good mainframe programmer. Microfocus had an expensive compiler/environment product that was able to emulate a few of these features, but I think it's out of market now.
   Anyway, dexterity with those features are usually acquired "on the shop" and very difficult (believe me) to get from a book or courseware.

That said, don't expect to get a mainframe job (other than a super-junior one) after learning and taming COBOL. That is just a first little step.

HTH!

Solution 3

There used to be a Cobol-to-C compiler and Eclipse IDE from a company called "The Kompany". The product was called "Kobol". It would let you write Cobol using an eclipse based environment that would be similar to what you would use for a mainframe (Rational Developer for Z). They have a free demo version and a cheap student version IIRC.

You will find that Cobol is easy to learn, easy to write and hard to shoot yourself in the foot with. That is one of the reasons it is so very popular with financial institutions.

I think it is great that you are adding Cobol to your toolbox.

Comments

[AJ.]

@duffymo - FWIW, I did take a functional programming class also, taught with PLT Scheme. :)

[Mikeon]

Is this for a class, or something you're doing on your own? Your question makes it sound like the latter, but if that's true you're certifiable. I did a bunch of COBOL in college, then got stuck working with it professionally for three years. It's really not a fun language.

[AJ.]

@AgentConundrum - this is not for school...learning it on my own. I only mention school here as a background to explain my lack-of COBOL exposure. Apparently I registered 20 years too late for that course.

[AJ.]

thanks, as enthusiastic as I am about learning COBOL (snicker), I definitely wouldn't want to break any laws in doing so. I will take a look at TinyCobol though, thanks for the tip!

[Dr. belisarius]

+1 for COBOL uses a unique mechanism to manage return from PERFORMed sections/paragraphs Pretty ugly things can be done by undisciplined programmers :)

[Dr. belisarius]

A comment on dating back to a time when procedure calls were considered costly : I think the tradition was also partly due to the lack of CVS (both in source and in compiled incarnations). I remember constructing a full blown CVS in Vollie (a defunct product, alla ICCF) just to persuade the programmers to reuse something