COBOL grouse

I dug out some of my old technical books from storage, looking for blog fodder. One of them was the book I really learned COBOL from, Greg Lupfer's DTSS COBOL: Introduction (1974), published by Dartmouth College's Kiewit Computation Center (DTSS is Dartmouth Time-Sharing System, and was an online environment that shared roots with Multics). There was a shelfload of copies of this book available to new programmers like me at Greg and Gary's consultancy in the early 1980s. For the most part, the presentation is no-nonsense, focusing on the features of COBOL 68 that you'd actually use to write business applications (with the exception of the Report Writer module, which has always been no more than a historical curiosity to me). The book is set throughout in a Courier-like font, and it looks like it was laid out with RUNOFF.

Using the example of an order entry system for a consumer audio store in Minnesota (with customers like R. Zimmerman from Hibbing!), Greg walks you through how an indexed-sequential file works, he explains figurative constants and the REDEFINES clause, and he touches on a few points of good programming practice. Early on is this deadpan gem:

The first program to be described is ORDER11. This program will accomplish the first step described above, which is to create a working data record that contains three additional fields used as the record progresses through the order edit module. The functions of these three fields are defined in the comments included in the IDENTIFICATION DIVISION of the program.

The name ORDER11, which seems to a rather unimaginative name for a program, is the result of an overall file naming convention that is used throughout the system described in this text.

Greg spells out a convention for naming source, object, transaction data, and master files within the constraints of eight (8) alphanumeric characters and no extensions. He then expostulates:

Most COBOL application systems use dozens of programs and files, so a consistent file naming convention is essential, and is to be preferred over assigning "meaningful" names to the files. These meaningful names often have meaning only to the programmer who wrote them. One actual system of seven programs used the names DOC, HAPPY, BASHFUL, SNEEZY, GRUMPY, SLEEPY, and DOPEY, and the programmer was not Ms. White. Any experienced programmer can probably recall similar instances of absurd names for programs. (pp. 22-23)

Greg didn't always follow his own advice. There was a legendary one-off that he wrote for a customer to scrub out unwanted control characters and other fluff. As the story goes, he named it REMOSHIT.