COBOL {Okay, Don't Laugh}?

I have lots of time on my hands now that I've retired, and I can only play so much guitar every day before they fall off. So, I spend a fair amount of time looking for projects to do.

Believe it or not, I made a good living writing COBOL code professionally, and while it's sort of on the "dead language" side of things, COBOL is still available. Curious, I ran cobc at a terminal prompt, expecting nothing. Instead, what I got was

Command 'cobc' not found, but can be installed with:
sudo apt install gnucobol3  # version 3.1.2-5, or
sudo apt install gnucobol4  # version 4.0~early~20200606-6

Interesting. I'm usually inclined to get the latest version, but that there are two versions available (and more documentation exists for the 3.x release) makes me stop and wonder: Which version should I install?

Additionally, geany is confirmed as a COBOL IDE whereas there is no mention of COBOL support in pulsar. I think I'm sticking with geany.

3 Likes

That's really interesting for gnucobol4 Visit homepage link in Synaptic points to https://gnucobol.sourceforge.io/ page which claims that GnuCOBOL 3.2 is the latest release.

3 Likes

Yeah, I found that out, too. After sniffing around a bit, I learned that gnucobol4 is (as indicated in the message) an early release. Which means it isn't fully baked, yet.

I decided to go ahead and install 3.2. There are pre-built binaries, but I still had to wrangle a bit with shared library objects and missing configuration files. Once that was remedied, I needed to run ldconfig again. But the test program ('hello.cob') ran without error. Checking, I noted the source code was 138 bytes and the executable was 16,888 bytes.

No one said COBOL was a minimalist lover's dream. :slight_smile:

2 Likes

I found my notes from 2014 ...

sudo apt install gnucobol (previously known as open-cobol)

compile with cobc -x -o file file.cob

001010 IDENTIFICATION DIVISION.
001020 PROGRAM-ID. FOREVERLOOP.
001030*
001040 DATA DIVISION.
001050 WORKING-STORAGE SECTION.
001060 01  WS-PROGRAM-NAME     PIC X(16)   VALUE "FOREVERLOOP  001".  
001080 01  WS-COBOL            PIC S9 COMP VALUE ZERO.
001090 01  WS-C                PIC S9 COMP VALUE 1.
001100 01  WS-FORTRAN          PIC S9 COMP VALUE 3.
001110 01  WS-ED1S             PIC Z-.
001110*
001010 PROCEDURE DIVISION.
001020     DISPLAY "I) PROGRAM ", WS-PROGRAM-NAME, " BEGINNING".
001030 0100-LOOP.
001040     ADD 1 TO WS-COBOL.
001045     MOVE WS-COBOL TO WS-ED1S.
001050     DISPLAY "I) COBOL AT ", WS-ED1S.
001060     IF WS-COBOL IS GREATER THAN WS-FORTRAN
001070         THEN GO TO 0800-ENDER.
001100     GO TO 0100-LOOP.
001110*
001120 0800-ENDER.
001130     DISPLAY "I) PROGRAM ", WS-PROGRAM-NAME, " TERMINATED".
001140*
001150     STOP RUN.
3 Likes

That code would be rejected at any facility I ever worked at due to the GO TO. I would always set a flag to control processing.

WORKING-STORAGE SECTION.
...
  01 END-OF-LOOP      PIC X.
  88 IS-END-OF-LOOP  VALUE "Y".

PROCEDURE DIVISION.

  PERFORM 0100-LOOP UNTIL IS-END-OF-LOOP.

0100-LOOP.
  READ SOMEFILE AT END
     MOVE "Y" TO END-OF-LOOP.
...

One of my first jobs as a programmer was to go through massive libraries of ancient COBOL code and clean up the programs by removing GO TO and ALTER and other fall-through spaghetti code.

I am proud to say I never used a GO TO construct in all my years of COBOL coding. In DOS batch files, yes. But never in COBOL.

Parenthetically, I was surprised to learn that COBOL is still alive and supported! Your example from 2014 shows that, and there is even a ISO/IEC 1989:2023 standard!

3 Likes

What a restless mind does after one retires. I am having a ball re-learning COBOL. A lot has changed since I wrote code for a living. The last company I worked for was an all-Java shop (I hate Java!) but now I'm free to pursue my own quirky wishes, and so I am. I wrote my first simple COBOL program today which gave me the impetus to re-build a piece of software I wrote back in the 1980s. Back then, I was handed a project to build a desktop system for a government agency using dBASE III+ . I got pretty good at it and developed a piece of shareware for internal use.

That internal use was running a football pool. The office was really excited about a weekly gambling event, and everything was done manually. I took it in hand to build an automated system, and ran the pool successfully for a number of years. I say it was shareware, but I never received any money for it (I didn't try to market it, and dBASE compilers weren't the best in the world, anyway).

What my early experiments and reading of GnuCOBOL is that the end result of a compiled COBOL progam is actually executable C machine code. That's right, the output of the COBOL compiler is then compiled and linked via C (gcc in most cases). The good news about that is that the final code isn't as bloated and "heavy" as native COBOL compiled code. At least that's what I've seen so far.

The best way I've found to learn software is to use it. When I was writing COBOL code, if I ran into a unusual situation, I'd research to find how to address it. After so many years, I'm not really starting from Square One, but with so many improvements and changes, I'm going to have to read the programmers guides, read examples, and run a lot of tests.

This is a ground-up project. I've started writing the project notes, and building the necessary data sources to build the work files.

But I'm retired, and this is a way to pass the time. And I find it fun!

5 Likes

That was a most interesting post, so thanks for sharing...

I can't recall the last time I actually wrote, or was paid for writing COBOL code, but I've always assumed as long as it was a database related app, I'd have no issues if I ever sat down and coded in COBOL again.

I can't really compare COBOL to anything else, resource/speed wise, as code was held together with [MVS] JCL & the only other language I recall using on those blue boxes was REXX & wouldn't make fair comparisons. I'd have expected a GNU COBOL to compile to other code, or re-use GCC code just like GNU Fortran did.

That is a good thing, in that languages need to change to survive.. but needing to look up manuals I fear we all do. Whilst I recall some of the bit-handling structures/codes in COBOL, I'd be so rusty I'd be almost guaranteed compile warnings/errors, or worse clean compile & useless non-working code (even corrupting data!)

I have positive memories of Clipper (summer-87 particularly for some reason comes to mind), but the language/compiled was geared for database handling, and not generic code. Maybe my memory just isn't that clear anymore either.


Well done for finding a project to have fun coding with, and exercising your mind!

2 Likes