Compile Listings in the Drawer
As a software engineer, I think it’s important to sometimes tell stories of things that happened, as my niece Amber likes to say, “Back in the day,” so they get a feel for the history of our craft.
My first job out of college with was Nationwide Insurance in Columbus, Ohio. When I got there, they told me they had just taken out the punched card reader, which surprised me that anyone was still using that technology.
Like many large insurance companies, these were COBOL systems. I was criticized by management sometimes for my use of “newfangled” ANSI ’85 COBOL constructs. Keep in mind, I started this job in 1990. This shows you the mindset of the company.
Memory Maps
For certain types of errors, especially memory overruns, the only way to diagnose certain problems was to use the memory map generated as part of the compile listing that showed the locations of the data structures. (These were S0C1, pronounced “sock one” and S0C4, pronounced “sock four” errors, for the historically interested.)
(Often, these were table overruns, so you had to multiply the table pointer by the table size to determine where the end of the table was. I used to love to do this when training new devs on how to debug them and would multiply the hexadecimal numbers by hand. This would blow their minds. I never told them that I was converting the numbers to decimal in my head, multiplying, then converting them back.)
Our daily update flow ran overnight and for some time. I got called in the middle of the night for some module I’d never heard of that had one of these errors. Online access had started but we didn’t have the compile listings in the system, so I had to drive downtown to get to the compile listings in the drawer. When I got there, the folder for that module was empty.
VS COBOL II
Nationwide was slowly converting over from the OS/VS COBOL compiler to the VS COBOL II compiler as the OS/VS compiler and it’s libraries were reaching end of life. There was a process where they were slowly moving the VS COBOL II libraries up in the system path so that all programs would be using those libraries.
There was a massive project coming to recompile all of the thousands of code units in our system to COBOL II. I thought it was crazy we were still using the OS/VS Compiler at all and made it a point to only compile programs in COBOL II, so that way I’d move a module, test it and deploy it one at a time instead of this massive conversion.
(I still remember the annoyance I felt when I had made changes to a module using ANSI ’85 structures [not supported by OS/VS COBOL] and compiled it under COBOL II and later found out that someone had made a change to that module, removed the ANSI ’85 code so that they could recompile under OS/VS COBOL.)
Fixing my Problem
Without the memory map, there was simply no solving this problem. The only way to get a memory map was to recompile the program. I saw that the program had not been recompiled for something like seven years, so even recompiling using the OS/VS COBOL compiler was unlikely to generate the same memory map and this was a good opportunity to port yet another module.
I recompiled it with the VS COBOL II compiler to generate a new memory map and moved the program to our production environment and asked them to rerun the job that failed. When it failed again, my plan was to resolve the problem using the new memory map I’d just created.
The Sysop told me that the job had wrapped up. It took me a minute to realize that it had completed successfully. Evidently, the problem had been fixed by recompiling to the new libraries. So I transmitted the new module into production, stuck the new program listing in the drawer, and called it a night. That program never blew up again during my time at Nationwide.