The Old Joel on Software Forum: Part 3 (of 5) - Resources for learning COBOL?

Resources for learning COBOL?

Of course, the first thing you're thinking is "why would somebody want learn COBOL now"? Well, they are rewriting an old mainframe system in a new language (yet to be decided) and I may get involved in the near future. Before you say "if it ain't broke don't fix it", in this is case it is broke and they have to fix it.

I won't be writing any actual COBOL code, I'll just need to be able to read it sometimes and know what to ask about it when conversing with the COBOL programmers. My involvement would mostly be in design and architecture of the new system to be written. To do a good job I believe I need to get a better understanding of the mind-set of COBOL programming -- why do so many COBOL programs tend to be 20,000 lines long, with rampant cut-and-paste? Is it the language that forced it, or is it because programmers of long ago didn't care about modularity?

Are there open source (or cheap) COBOL compilers that are similar in flavor to the old mainframe COBOLs, that will run on a Windows or Linux PC? (i.e. not Micro Focus Object-Oriented COBOL.) What books would you recommend? Web sites? (I've done some web searching, but not sure what to choose.)

T. Norman
Thursday, January 29, 2004

The textbook we used in school was "Structured COBOL Programming" by Shelley Cashman.

Dave B.
Thursday, January 29, 2004

To think, I threw out a load of COBOL books a few years back...

SC
Thursday, January 29, 2004

I learned COBOL about a year ago for work. I still have the book, COBOL for the 21st Century. http://www.amazon.com/exec/obidos/tg/detail/-/0471073210/qid=1075434355/sr=1-1/ref=sr_1_1/104-1666095-1811114?v=glance&s=books

The book does a good job of covering the basic material and moving quickly through a large swath of syntax. COBOL doesn't get too deep so you shouldn't have much of a problem.

As for why COBOL programs are 20,000 lines long compared to a C++ program that's only 2,000 lines - COBOL is verbose, really verbose. That's great for maintenance, but it sucks for modularity. Speaking of which, lots of old COBOL code isn't very modular at all. Why? COBOL wasn't really designed with code reuse in mind the same way we think of it now, and a lot of good programming practices have come into existance after COBOL was being used. So you get code that's long and repetitious (and the language doesn't really help).

A couple of notes about COBOL that are likely to catch your eye and potentially confuse you.
1) Files aren't directly declared in the program, you write an interface to the file and define the layout (possibly locally, possibly in another file called a CopyLib). The files are tied in to the program on execution (via a JCL deck).
2) Variables can be redefined. I might say that a file layout is an 80 character string, but later redefine it as 8 10 character strings because it's easier for me to move the data around when I need to, and loop through it in chunks when I need to.
3) Every variable is global - and everything must be defined before hand. Working storage is where nearly all variables live. And variables are either numbers or characters ( x(9) means a nine character array/string, 9(9)v99 means a nine digit number followed by a decimal point (v) and two more numbers)
4) You'll probably see lots of "execute 300-process-payroll thru 300-exit" - that's a way of handling errors without totally disrupting the program flow that will seem really counter-intuitive. Just watch the program flow and you'll be fine.
5) Watch the program flow, COBOL programs tend to have GO-TOs and they also can execute series of commands (the thru) that aren't defined by the number predecessor (300-process-payroll thru 400-write-records might include 600-crash-program-unexpectedly if 600-.... is listed in the source between 300-... and 400-...)
6) Periods used to end IF statements and nearly everything else, then in COBOL II there was an End-If statement added and periods weren't generally required, so watch out for that and just try to be aware of what's happening. Never trust the periods!

Good luck!

Lou
Thursday, January 29, 2004

T. Norman wrote, "My involvement would mostly be in design and architecture of the new system to be written. To do a good job I believe I need to get a better understanding of the mind-set of COBOL programming "

I say don't waste your time unless management is mandating that you must. I am assuming that:

* Tthe COBOL programmers working on the team are responsible for explaining how the old system currently works.

* There is little or no documentation available.

* The new software system will be designed in an component based object-oriented manner as opposed to procedurally.

Imo, "to do a good job" designing and architecting the new system you are probably going to need to understand what the old system was designed to do and what the new system is suppose to do (the same thing, a few things differently, etc.). Understanding the old software system falls under basic system analysis (i.e. asking lots of questions):

* Is there any documentation available?
* Which techies understand this system?
* Is this a batch system, an online system, or both?
* What are the inputs?
* What are the outputs?
* Where is the data being stored?
* Who are the end users?

One Programmer's Opinion
Friday, January 30, 2004

Your guys forgot to tip the guy on the most idiotic thing in COBOL:

If you don't start writing instructions starting at a certain column, the compiler will report countless meaningless errors.

You have to start every instruction at the eigth column or something - that is, put 7 spaces before it.

Somebody should track down and kill the dork that made that decision.

No, better, somebody should find him or her and torture him to death!

KRAD
Friday, January 30, 2004

OPO: I am not trying to become a COBOL expert. But I do believe in getting my hands dirty in the trenches in order to increase the chances of doing a good job. Like when Stallone did Rocky, he trained just like a boxer would, taking facial cuts and broken ribs in the process in order to gain a better understanding of what he was trying to emulate.

I also had the intention to learn COBOL anyway for the past few years, for the purpose of expanding my knowledge of the various major "mind-sets" of programming. Major programming mind-sets include (but are not limited to):

- Assembly
- Pointer-based languages like C
- Object Oriented languages
- GUI builders like VB/Powerbuilder/Delphi
- SQL and stored procedures
- The LISP family
- COBOL (and similar languages)

I've done all of the above except the last 2. As I gain increasing technical responsibilities in the organization, cutting across various systems, I think it is important to have an awareness of all the mind-sets of the systems which I have to interact with.

T. Norman
Friday, January 30, 2004

Hi T. Norman,

When you have the time perhaps you can explain to me what your major job responsibilities are and what your job title is. It sounds to me like you might be playing the role of a programmer analyst (someone who conducts systems investigations, develops design specifications, and writes software to implement the design) but have been given a job title with a different name.

"Like when Stallone did Rocky, ..."

Well, your analogy doesn't work for me, however, I think I understand the point you are trying to make.

Are you both an actor and a director? While Stallone wrote the script for Rocky and of course played the starring role in this movie, he didn't direct it. A director is a big picture type of guy while an actor doesn't necessarily have to be.

"...for the purpose of expanding my knowledge of the various major "mind-sets" of programming."

I still don't see how learning how to write a basic COBOL program is going to help you very much.

"I think it is important to have an awareness of all the mind-sets of the systems which I have to interact with."

Understanding the syntax of a procedural programming language and understanding procedural based software development are two different things. For example, a long time ago I wrote a decision support application using Visual Basic version 3.0. The way I coded this particular program was nothing like the way I would have coded a COBOL program, however, the structured design methods that I used were same one that I would have used in a mainframe computing environment (I created a data flow diagram, a data dictionary, a database design, a structure chart, etc.).

My point is this. With the documentation that I created a system analysts/architect/programmer analyst/etc. would have been able to understand what my program did without knowing a thing about the Visual Basic programming language. Lets pretend this system analysts was tasked with rewriting my applications using C#. In order to accomplish this goal all the analyst would need to do is look at my documentation and play with the executable just like an end-user would. He really wouldn't need to know anything about my source code.

"...Well, they are rewriting an old mainframe system in a new language (yet to be decided) and I may get involved in the near future."

If your organization is trying to create a new software system using OO techniques then understanding COBOL's syntax won't help you (an architect?) very much. Why? Because procedural code can't be easily transformed into object-oriented code just like you can't convert a data flow diagram into a class diagram (well you might be able to do it but I wouldn't recommend trying to do so).

One Programmer's Opinion
Friday, January 30, 2004

"...the most idiotic thing in COBOL...You have to start every instruction at the eigth column or something..."

Well, it made sense back when they used punchcards. Or perhaps you enjoy manually sorting a stack of punchcards.

(Not that I'm old enough to have used punchcards myself, but anyway...)

Kyralessa
Friday, January 30, 2004

"...the most idiotic thing in COBOL...You have to start every instruction at the eigth column or something..."

The last time I touched COBOL professionally (about 10 years ago...), there were very few COBOL compilers that still enforced this unless you set the 'take me back to the good-old-days' compiler switch.

I seriously doubt (well, hope...) that even fewer do so now.

RocketJeff
Friday, January 30, 2004

Almost forgot the original topic...

If you want to learn COBOL programming, there are a couple of books that seem to get decent praise:

C for Cobol Programmers : A Business Approach - http://www.bestwebbuys.com/books/compare/isbn/0805316604

Teach Yourself COBOL in 21 Days - http://www.bestwebbuys.com/books/compare/isbn/0672317885 (yes, I know it's one of the dreaded '21 days' books, but it's supposed to give a nice introduction to COBOL)

RocketJeff
Friday, January 30, 2004

Don't bother learnining COBOL... it is a huge waste of time. I made quite a bit of cash during Y2K knowing it, but companies these days do NOT want COBOL programmers. There is still a newsgroup that tries to convince themselves that COBOL rocks... but not only does it suck as a procedural language (which C, for all intents and purposes still commands attention), but it cannot properly move into the OO realm. I've seen OO COBOL (as a Java programmer) and it is just as bad as all the COBOL client code I've ever tried to convert.

COBOL is like one big DTO language. If you know what I'm talking about, you'll know what I mean..................

it is as it is
Saturday, February 21, 2004