Once upon a time, in a land far from any modern developers, were languages named COBOL and PL/I, which generated programs that were consumed by a beast known as Mainframe. Developers for those languages compiled and linked their applications huddled around strange luminous green screens and piles of hole filled papers while chanting vaguely latin sounding incantations like “Om-padre-JCL-beget-loadmodule-pee-dee-ess.”

In these ancient times, version control tools like git were not available. There was no notion of makefiles, so compilation and link was a batch process, with no dependency tracking, and no parallelism. Developers used printf-style debugging, logging trace information to files. In order to keep the uninitiated from talking to the Mainframe, files were called datasets. In order to use graphical editors, developers had to repeatedly feed their source to the Mainframe using a slave named ftp, while praying that the evil demon EBCDIC-conversion didn’t mangle their work. The next day, they could go back and see if Mainframe accepted their offering.

[TO BE CONTINUED.]

Incidentally, as of a couple days ago, I’ve now been working for LzLabs for 2 years. My work is not yet released, nor announced, so I can’t discuss it here yet, but it can be summarized as really awesome. I’m still having lots of fun with my development work, even if I have to talk in languages that the beast understands.

Share this:

and coded the chapter 1 compound interest calculation myself before looking at the solution. I was surprised to see that (n)vim has built in syntax highlighting for COBOL. It even helps position the comments and line starts in the right places, which was handy.

Having been horrified any time in the past that I saw COBOL code, it feels weird to be coding my own hello-world in the language, but it works, and with ALL CAPS output, it looks sufficiently dinosaur’ish to be COBOL:

./interest
-----------------------------------------------
TO END PROGRAM, ENTER 0.
ENTER THE INVESTMENT AMOUNT.
1000
ENTER THE NUMBER OF YEARS.
1
ENTER THE INTEREST-RATE.
1
FUTURE-VALUE = 0001010.00
-----------------------------------------------
TO END PROGRAM, ENTER 0.
ENTER THE INVESTMENT AMOUNT.
1000
ENTER THE NUMBER OF YEARS.
2
ENTER THE INTEREST-RATE.
1
FUTURE-VALUE = 0001020.10
-----------------------------------------------
TO END PROGRAM, ENTER 0.
ENTER THE INVESTMENT AMOUNT.
0
END OF SESSION.

Notes and questions:

I wasn’t sure about when I had to use statement terminators (.’s) in the ELSE body, so I moved the whole basic block to a helper function.

I got messed up initially with the syntax for the PIC values at first, as I’d used .’s instead of V’s to specify that my variables were numeric. This caused cobc (gnu-cobol front end) to complain that INTEREST-AMOUNT was not numeric, and I eventually found the answer in the PIC table of the book.

The point of this exercise was probably to use a loop, which I avoided by calculating the value in one shot. I’ll have to go back and see how to do that.

There doesn’t seem to be any notion of function prototype, and the function bodies can be either before or after their calls.

Functions are annoyingly, but appropriately (given the requirement to be over the top verbose for many things), called PARAGRAPHs in COBOL. I wonder what the mainframe does with name mangling, given that symbol names have to be 8 characters, and COBOL function names are up to 30. Perhaps only the external entry points (the program-id?), have that restriction?

cobc’s implementation of -g sucks, and a debug session shows the lines of the generated .c files instead of the COBOL sources. There ought to at least be #line markers in the generated C sources instead of comments.

In code that I am writing for work, I’m calling into COBOL code from C, and in order to setup the parameters and interpret the results, I have to know a little bit about how variables are declared in COBOL. I got an explanation of a little bit of COBOL syntax today that takes some of the mystery away.

Here’s the equivalent of something like a declaration of compile time constant variables in COBOL, a hierarchical beast something akin to a structure:

The first 6 characters are source sequence numbers. They aren’t line numbers like in BASIC (ie. you wouldn’t do a ‘goto 004500’), but were related to punch cards to make sure that out of sequence cards weren’t inserted into the card reader, or a card wasn’t fed into the reader by the operator by accident.

The ‘ORIG_SRC’ stuff in column 73+ are ignored. These columns are also related to punch cards, as an additional card sequence number could be encoded in those locations.

The 01 indicates the first level of the ‘structure’.

The 02 means a second level. I don’t know if the indenting of the 01, 02 is significant, but I suspect not.

PIC or PICTURE basically means the structure line is a variable and not the name of a new level.

A sequence of 9’s means that the variable takes numeric digits in those locations, whereas the V means that location is a period.

A sequence of X’s (or the X(5) here that means XXXXX), means that those characters can be alphanumeric.

There is no reference to ‘CONSTANT-VALUES’ when the variables are referenced. That is like a namespace of some sort.

The level indicators 01, 02 are arbitrary, but have to be less than 77 (why that magic number? … who knows). For example 05, 10 could have been used, so that another level could have been inserted in between without renumbering things.

The 01, 02 level indicators are also used for global variable declarations, also somewhat struct like:

The 0x80000000 is the mainframe “31-bit” way of indicating the end of list. It relies on the fact that virtual memory addresses in 32-bit z/OS processes have only 31-bits of addressable space available, so you can hack one extra bit into a pointer to indicate end of list of pointers.

Suppose the program has statements like the following to populate its output fields

Share this:

Usually, I’m really eager to open a package containing a book. This time I wasn’t so sure I actually wanted to open this mail item, since I knew exactly what it contained:

I’ve got work to do related to C, PL/1, and COBOL. I don’t have the courage to buy myself any sort of COBOL book. I saw COBOL once and my eyes burned. My eyes are watering even thinking back to that day. Unfortunately, at a glance, PL/1 doesn’t look much better than my nightmares of COBOL.