• Please review our updated Terms and Rules here

COBOL

Status
Not open for further replies.
The main problem with COBOL was that it was designed on the assumption that programmers could write syntactically correct English and spell long words like identification, environment, configuration and subtract. Even those of us who could would have preferred not to.

Some programmers on our site found it so boring that they would obfuscate their code by using irrelevant variable names just so that they could write statements like "ADD BLUE TO YELLOW GIVING GREEN." The program would work perfectly but nobody else could understand how it was doing it. It was claimed that COBOL was self-documenting but actually it depended entirely on how one used it.
 
Lordy, it could get bad. I once worked on a military logistics project (vendor's side) where the client had enrolled 1500 programmers to spew COBOL (on the vendor's side, we were only 70). Every global variable had to be described in a massive "Data Dictionary" (the paper sort) and be no less than 30 characters long. I am not making this up.
 
I recall that we had a COBOL program written by the US Navy, the spiritual home of COBOL, which supposedly drew flowcharts from COBOL source code. That had appallingly long variable names throughout and the contents of the variables were equally unnecessarily long. There was a logical flag in the source code parsing routine named IS-THIS-A-SENTENCE which had possible values YES, NO and somewhat oddly WAS so that the test on it read IF IS-THIS-A-SENTENCE EQUALS "YES" ... These values weren't equated to single character values, so the flags themselves occupied three text characters in memory. Apart from its tediously long source code we never got the program to work properly, at least not on the source code for our programs. It printed the flowchart on continuous line printer stationery but for some reason flow lines had a habit of disappearing through the perforations between the pages and not appearing on the next page. Clever people, these naval programmers. We never did work out how they managed to do that but maybe it was a comment on our program structure.

Apparently COBOL's creator Grace Hopper died in January 1992 and the first text message to a mobile phone was sent at the end of that year, so she never had to endure the extreme brevity of texting and trying to fit her words into 160 characters. Just as well really. By the time computers became capable of parsing normal language young people gave up using it. Just typical!
 
Our customer wasn't USN, but USAF. Same mind-set. I recall delivering a reel of updates to a base installation and after checking with the (two) operators, made for an empty tape drive before being stopped by a loud "HEY! STOP!". It seems that they had airmen standing by to mount tapes and that I was taking some poor guy's job away from mounting a tape. (BTW, I later learned that they kept a paper log book of every tape mounted on every specific drive). Had I tried to mount a disk pack, I probably would have been shot.

The military and computers were very strange...
 
Most of the COBOL code I encountered was very nicely commented and clear. I had a sideline converting COBOL to more modern environments and it was a breeze. My consulting rates must have been too low since the clients weren't simply running the code through a more recent COBOL compiler. It was nice having clients that accepted my penchant for excessive comments.

My dreaded code involved a client that stored all their files in DBF files names with vulgarities. Fortunately, I never had to engage in a phone discussion involving determining what the fields in a file meant because that would have sounded like a tirade that would have been considered excessive back when I was in the Army.
 
RobS said:
I recall that we had a COBOL program written by the US Navy, the spiritual home of COBOL, which supposedly drew flowcharts from COBOL source code. That had appallingly long variable names throughout and the contents of the variables were equally unnecessarily long. There was a logical flag in the source code parsing routine named IS-THIS-A-SENTENCE which had possible values YES, NO and somewhat oddly WAS so that the test on it read IF IS-THIS-A-SENTENCE EQUALS "YES" ... These values weren't equated to single character values, so the flags themselves occupied three text characters in memory. Apart from its tediously long source code we never got the program to work properly, at least not on the source code for our programs. It printed the flowchart on continuous line printer stationery but for some reason flow lines had a habit of disappearing through the perforations between the pages and not appearing on the next page. Clever people, these naval programmers. We never did work out how they managed to do that but maybe it was a comment on our program structure.

Apparently COBOL's creator Grace Hopper died in January 1992 and the first text message to a mobile phone was sent at the end of that year, so she never had to endure the extreme brevity of texting and trying to fit her words into 160 characters. Just as well really. By the time computers became capable of parsing normal language young people gave up using it. Just typical!
Click to expand...
That would be Rear Admiral Grace Hopper.
 
I had only one encounter with Cobol.
A friend was rehired by his previous employer, after being made redundant, to do Y2K fixes to the code he had been maintaining for a number of years.
He had been stuck for several days with an issue, and asked me to review the code for typos, as a variable wasn't returning the expected result.

I didn't find a coding issue, but suggested maybe it was being overwritten by an overflow from another variable.
A dummy variable was placed on either side of the problem one and the problem then disappeared.
He was very happy and I probably found a cobol bug - Micro Focus if I recall correctly.
 
Agent Orange said:
That would be Rear Admiral Grace Hopper.
Click to expand...
... building on the female legacy of Ada Lovelace, who was much better looking. I know nothing about the ADA language but have read that that is also heavily used by the DoD. So are we going to get a humorous picture about ADA now? Old ladies reprogramming fly by wire fighter planes maybe? No, you'd need a heavy transport plane to carry Babbage's computer onboard ... along with the steam engine to power it.

By the way, it might be my peculiar imagination but the ladies in that picture remind me of the three witches in Shakespeare's Scottish play cooking up a spell. My wife and I recently went to see a very mediocre version of the play at our local theatre and for some reason the witches were dressed as nuns, which didn't have quite the same impact. We wondered whether the acting company had forgotten to pack the witches' costumes and had to make do with what they had to hand.
 
Last edited:
I programmed in COBOL during the late 80s - early 90s. It was pretty easy to work with on the Sperry-Univac mainframe.
After that I transferred to another department and programmed in Unisys MAPPER - another fine language that's gone the way of the dinosaur.
Fortunately I was able to get a Windows version of MAPPER (now called BIS) and still use it most days for my personal stuff.
 
My dad was a skilled COBOL programmer when I was growing up. He worked a lot with IBM and contracted out to GM and some other companies IIRC. Eventually he landed at the State of Michigan and retired from there. He was one of their last COBOL programmers and also knew their Unisys Mainframes.

I remember when they got a newer Mainframe when I was a teenager. He took me to work on 'take your kid to work day' and showed me around the data center, raised flooring, tape backup systems; it was pretty neat. The newer mainframe was replacing an entire room of them.

One of the reasons I still almost never gamble is because of my dad; while we were at his work that day, we went around the office and took fake lottery picks of 5 numbers from a bunch of people. He bet 1 2 3 4 5, straight, and told me if he wrote a program to ran an obscene number of drawings (10s of millions, from memory) that he would win the same number of time as everybody else's picks. And he was right.
 
If you were a veteran retired COBOL programmer in the late 1990s, you could pick up quite a bit of cash by hiring yourself out to fix COBOL programs for Y2K. Even then, people with facility for COBOL were in short supply. 50 years ago, one of my early jobs was maintaining a COBOL dialect translation program. It was written by an interesting fellow on contract and a favorite chum of Bill Norris. He played a mean game of petanque and lived with a bunch of gypsies up in the Santa Cruz mountains. He'd come down to the valley and hire himself out when he ran out of money. Odd thing was that prior to his then-current life, he was a strait-laced IBMer who worked on the IBM COMTRAN project. He quit when he was assigned to the PL/I project, whom he called "a bunch of misfits and drunks". I learned a lot from him.

Languages in use by the military? Let's talk JOVIAL!
 
Chuck(G) said:
If you were a veteran retired COBOL programmer in the late 1990s, you could pick up quite a bit of cash by hiring yourself out to fix COBOL programs for Y2K.
Click to expand...
Not Y2K specific, but this created quite the fiasco in MI at one point. I don't think this one was really public common knowledge but basically in the 90s guys were retiring from the state of MI, collecting their pensions, and simultaneously taking contract work with the state. This resulted in a regulation that retired / pension-collecting employees couldn't take contract/for-profit jobs from the state. Sounds good until 2 of the last 3 Cobol programmers and mainframe admins retire, and a consultancy firm over-writes an entire production database with test data. They literally could not legally pay my dad or his friend to come in and fix it. My dad refused, his friend went in and restored the entire DB (A very important one to say the least) from approximately 48 hour old tape backups. "Have fun re-entering the last 2 days of data, and never call me again."
 
A lot of COBOL even in 2000 originated in the days of the second-generation mainframes. IBM made a pile of cash with various emulation modes available in their S/360 and S/370 systems, such as 7080 and 1401. Before S/360, the IBM computer scene was mishmash of various architectures. That got to be fun when you're trying to update code running in 7080 emulation mode with Autocoder patches. I recall that the state of California tried to update their antiquated DMV system several times, with disastrous results.

Grace Hopper, bless her soul, was a visionary when it came to COBOL. As far as I'm aware, she was the first to push standardization among vendor dialects. The Navy Audit Tests for COBOL were dreaded by compiler types for years, and I think it was around 1975, that CODASYL declared that vendor extensions to the language had to be specifically enabled by the user; the default was to be an absolutely standard-conforming compiler.

At Control Data, the grand panjandrum of COBOL was Don Nelson, a jolly bearded fellow who played bass drum in the Los Trancos Woods marching band. Things were different back then. Money ruined the Santa Clara valley in my opinion.
 
Is this thread still actually meant to be a joke bearing in mind how it started? If so it seems more like a shaggy dog story to me and we're all going to be very disappointed when we finally get to the punch line, but then that's probably how we feel about COBOL as well. Fortunately after only a few years I moved into system design and didn't need to think about how the programmers created the mainframe programs for me any more. Later I took up programming PCs with all the weird and wonderful tools available for them under OS/2 and Windows.
 
Our HP 3000 running MPE/iX had a web server, it was written entirely in COBOL. It worked fine. The primary issue was with MPE's file system. It had a 2 level deep hierarchy based on file ownership. So a URL like http ... /bob/index.html would be turned into .BOB.INDEX.HTML in MPE's account.group.file naming format. The account and group components were used to create a fake 2 level directory hierarchy. It also supported all the wonderful and odd file types MPE supported, like circular queues, lifos, fifos, and so on.
 
Status
Not open for further replies.
Back
Top