The gift of Grace: COBOL's odyssey from Vietnam to the Square Mile Cobol is the language most associated with mainframes, especially the IBM System 360 whose 50th anniversary is being celebrated or at least commemorated this week. But when COBOL was first spawned in the mid-1950s, it wasn’t intended for programmers. It was aimed instead at “accountants and business managers” – basically a …
Exactly so. COBOL was of its time and it should not be criticised for not being designed with 30 years of nonexistent hindsight. It was designed in a day when the whole understanding of what a computer was and what it did was very different, when the work to be done by a compiler had to be minimised because processing power was expensive. As noted in TFA, it was originally seen as a language to be used by technical people to solve problems in their discipline, not to be used by a special class of programmers. Rather like ALGOL and FORTRAN, in fact.
The number of academic languages which are theoretically wonderful that have emerged since, and which have sunk, if not without trace, at least into footnotes, is evidence that sometimes what people are used to is actually the best solution.
I actually heard Grace Hopper speak several tiems and her story was that she and her coworkers who Designed COBOL had two major objectives:
1) A Language that did the things Business needed to do. That's why they called it: COmmon Business Oriented Language.
2) A language that looked enough like English that it would be Easy to teach and read. That was one of the reasons the Pentagon helped Pay for the development of COBOL. They were looking for a language that could be taught to the average Military Recruit with a High School Education in a short period of time.
They also knew exactly how difficult it is to find the Time to Document the program when yur Manager is breathing down your neck. So, they added "Self Documenting" to the list of attributes. Yet another push in the direction of "Looks Like English".
The fact that so many COBOL programs are still chugging along, just doing the job, is proof that Hopper and friends succeded in meeting 99% of their objectives.
Oh, and when it comes down to the accusation of "Wordiness", how many pages worth of reading is required for a Properly Documented C++ Program that the next programmer can just pick up and figure out what it's REALLY Doing??
In 1980, I was in first year at university and had holiday jobs working in various computer places.
Back then, most COBOL programmers had only a three month programming course and that was it.
Essentially, they took the more intelligent looking filing clerks and ran them through a 3 month course from IBM, ICL, or whatever, and out popped a newly minted COBOL programmer who could convert flowcharts into COBOL. THe better ones could even generate the flowcharts too.
They could do basic stuff like inventory, accounting, etc. COBOL was great for that task.
Many of these programmers got a bit big headed. They were needed to produce the end of month accounts and could weedle various favours out of management.
In about 1986, one place I worked at discovered desktop computers (Macs) running spread sheets. Suddenly managers could generate their own reports without some of these COBOL programmers holding them hostage. Many of the most dickish programmers were quickly fired.
Never been fond of it, even though I've done a fair bit over the years. It got slightly more tolerable when Cobol 2 came along and you didn't have to type with your little finger constantly on the shift key though. As Dominic points out, insanely verbose though, especially when people insisted that variable (or "field") names should be suitably meaningful. Not fun on 3270's without cut'n'paste. These days, of course, IBM do perfectly good 'C' and C++ compilers which work nicely with any s/360-derived data formats if you avoid that string malarky, and there is a perfectly good JVM if you really enjoy typing (pun intended).
I guess it was popular simply because it was intended for accountants and business managers; just unfortunate that, whilst a language syntax may be relatively easy to pick up, writing decent software, for any purpose, remains rather hard.
But the (wholly intentional) advantage of its verbosity is that you could take a section of procedural code and show it to an intelligent accountant or business manager (yes, they do exist, honestly) and explain what it was meant to do. If you were lucky, they might even be able to point out why what you were attempting to achieve wasn't actually what the business needed.
Try doing that in C.
"insanely verbose"
ISTR editors allowed macros that allowed simple keypresses to fill most shit GIVING ease of use.
Can't remember when CAPS LOCK first came in but my old typewriter had it - though you couldn't easily use it to write templates and macros that could do 90% of the work once you'd worked out a name for the PROGRAM-ID.
I loved writing COBOL on the Vax - EDT and TPU FTW.
I miss those "simple" days. I think the verbosity of the code was really nice, you felt you had acheived something when you had written a screen full of code. With C, in the same vertical space you probably had 2 lines of code and 20 lines curly braces! :-P
I Remember hearing the the screaming of the line printer, coming to a halt and then seeing one of the programmers reach down and pick up 6 inches of green bar so he could see what was wrong. After several iterations of this the printer seemed to quiet down for quite a while. He must be back at his desk trying to figure out what the compiler dump printout said. All in a day's work I guess. I always knew that it was the programmers because the first page always had their name on it instead of a program name! The programmers must have decimated hundreds of square miles of forest with their printouts!
"writing decent software, for any purpose, remains rather hard."
I don't think this was fully appreciated at the time. You only have to look at the futurological predictions to realise that people always underestimate just how difficult new technology is going to prove (e.g. "flying cars" - they exist all right, but it turned out that helicopters were hugely expensive, fuel-inefficient and need highly skilled and trained people to operate. Or fusion, which is now more years in the future than it was thought to be in the 1960s.)
You could argue that people should by now make allowances for underestimation of difficulty, but people with money tend to get the jitters when you put even 20% of contingency into a project. And perhaps being economical with the forecast is right; if the US Government had realised how expensive the Manhattan Project was really going to be, they would probably have invested in improvements to conventional weapons instead. Sometimes you just need to take a walk in the dark to make progress.
Actually the COBOL PICTURE stuff used for formating reports (COBOL's bread and butter), is far less verbose than attempting the same thing in C.
So is the record copying: Copy a record of one type to another type and all the fields with common names get copied across. One line does what n lines of C/Algol/Pascal/... does and does not need to be changed when the field names are changed.
COBOL is incredibly useful, and reasonably succinct, when used for what it was intended for.
Don't try writing an OS in COBOL though...
"Not fun on 3270's without cut'n'paste"? It was simply a different paradigm, that's all. Who needed cut'n'paste when you had ISPF edit? Incredibly powerful - if you grew up with it, you could make it jump through hoops. Far from needing cut and paste, when a GUI interface was all I had, I missed the sheer raw power of Edit's command line. In my later years, I had a rich choice of coding environments; I used GUIs for some languages, such as Java, but 3270 for others (most definitely including COBOL) . Horses for courses, and all that.
I started in other languages, and came to COBOL late-ish in my career (supporting CICS development - and I consciously started writing my code in COBOL because, yes, that's what a lot of the customers I talked to were still using). Yes, it had lots of annoying details - and until COBOL 2 came along, some serious linguistic omissions too - but of all the annoyances, the biggest one of the lot for me was that comparatively trivial, and wretched, terminating period. Absolutely mandatory in some places; a syntax error after the self-same statement in others. Slap a conditional around a piece of perfectly good, working code, and suddenly it wouldn't even compile. If I'd had a swear jar in the office, it would have been full about twice a day.
If there really are a million COBOL (I'm old school) programmers out there, I bet their average age isn't much less than 50. So you're losing getting on for 10% of your 'stock' every year, most (hopefully) to well-earned retirement. So who's going to maintain your 100,000 COBOL programs in 10 years time? Do you have a cunning plan to rewrite/redevelop them all in some hip modern language? How many programmers do you need to rewrite 10,000 programs a year?
I've got lots of questions, but I don't hear many answers.
"So who's going to maintain your 100,000 COBOL programs in 10 years time?"
Me and a whole bunch of like-minded guys. Our motto shall be "You don't need a new data center, you need people who won't sneer at the one you've got".
Working on the details as I type. Meanwhile, back to your desk to find that missing semi-colon or malformed (but entirely compiler legal) "if" equality that is needlessly crippling the general ledger.
8o)
Aw 'cmon - you could spend days debugging a COBOL program if the punch girl missed a slightly faint full-stop. And, despite my disinclination to type long variable names (and let the compiler find the typo's), to this day I habitually put a horizontal bar through 7's and Z's when I write them down.
I would say that COBOL has achieved its longevity (we are talking about mainframes here) largely through:
a) IBM making the s/360, S/370, etc. architectures backward-compatible (genius IMHO)
b) Programming in assembly language being just too hard/too easy to create nightmares out of.
Pace that COBOL ur-program mentioned above - I'll bet it was a sequential batch update ported from the original assembler by someone who happened to be extremely proud of their penmanship!
Well *I* didn't have to because my mired-in-the-50s-mindset factory used verifiers, so most typos got caught.
I slash zeros and write G with a big tail on it too as a legacy of coding sheets, but since confusion between letters and numbers is still cause for concern when typing is not an option I view it as a positive rather than as reason to start drinking the Java Kool-Aid.
But why on earth would you use an IBM machine to do what a Unisys Sperry (or Burroughs) node in a 2200 does so much better and so much more securely on every level? IBM have only ten years of one technology that was done tested rolled out and earning its keep in 1992 on Unisys machines.
I still remember being asked by an IBM DBA "When you lose a disk in the online day and have to recover, how much data do you lose?" and me standing there like a numpty trying to understand his question, because for over a decade the answer for me had been "none" and I'd forgotten the bad old days pre-integrated recovery.
Its just another language. Not that big a deal. So I bet that in big cobol using companies astute folks in their 40s who fancy the idea of steady employment until the pension fund is healthy enough, might be saying hey boss, let me work with old Bill until he retires and I'll learn that stuff so we are covered.
the fourth, or should that be the third is "The Psychology of Everyday Things" Should be mandatory reading for any UI designer. Trying to use some of these fondleslabs makes me wonder why I don't see more electronic devices smashed on pavement. But I digress. Anyone try Fujitsu Visual Cobol ? Pity it was not as easy to use as MicroFocus.. The idea of resurecting the Screen Painter was good, but the usual COBOL dialect differences made me drop it for Delphi. Now what happened to Kylix on Linux ? About time someone tried again.
Back in the eighties the degree that I was studying COBOL was a good part of it.
Never used it after I was finished with the degree, but the one lasting thing it did do was to teach me how to spell "environment" correctly. Without COBOL I'd still be misspelling that word.
That's only pants because it's not:
DIVIDE cake INTO 8 GIVING slices
If you can read that you can understand it. I think that's how computer languages should work, let the compiler/interpreter take care of converting it to machine, I want something I can read!
If anything, Python has the worst punctuation.
The python punctuation is whitespace and impossible to see. I've had python code mangled by editors, emailing and the like which took ages to fix.
At least if C code gets mangled it is reasonably easy to fix with a pretty printer.
Another calumny spread by the one-course wonders.
You could write DIVIDE cake BY 8 GIVING slices even on the old ICL 1901T.
So double 8oP to Anonymous Ivy, too idle to crack a manual.
If you wanted to live dangerously you could COMPUTE slices=cake/8 but that is a Cobol 101 error in the making. Rule of Thumb: If you let the computer decide, it will decide on the worst possible option for your desired outcome. Works for just about everything, even today, even using C-like languages on Unix-like operating systems.
Dominic Connor worked on getting Cobol to work properly under OS/2, which was so successful that he’s now a City headhunter.
If ever there was a time when the City needed new heads a’hunted, DC, it is now, for its key secret* is reverse engineered to base foundation and realised to be indefensibly vulnerable to simple text based complex attack/SMARTR IntelAIgent Discourse.
* Don’t let anyone fool you into thinking and wasting time on discovering secrets, plural, when its key secret, singular, rules over everything under the sun. And it be priceless and worth whatever it takes and is asked, to keep it a closely guarded secret known only to a carefully vetted few, who invariably have been clever enough to work things out for themselves too, making it a sort of autonomous, self-actuated and self-actuating group, practically astute, virtually anonymous and highly active.
Play the wrong game against them, and the secret universal control mechanism of which we speak, the City’s key secret, is made known to everyone worldwide in a language which they cannot fail to perfectly understand. And one wouldn’t want to be a big City player whenever that info hit the fan and main street, for the baying mobs will not be stopped having their rightful revenge on the source of all of their pains.
It wasn't just the big companies that used COBOL. In the late 80s we were taught COBOL on a BTEC computing course at college. It seemed on its last legs even then: having to write out the code on coding sheets to be entered by a roomful of typists; getting your program back with one typo, you had to watch everyone else gleefully calculate the compound interest on a 15-year loan. The one we used was called Flinders COBOL, if i remember rightly, and ran on a Prime Computer. A year after finishing the course, I visited the campus, and saw all the Prime terminals piled up in a skip.
It's perhaps interesting to ask whether the coding sheets method actually made for better programmers. Nowadays auto suggest and complete and instant debugging has made the skill of being able to write code without trivial errors somewhat redundant - but from my old fart perspective, striving for 100% accuracy first time was good mental discipline.
We also need to remember that for server side code, writing the code using an IDE is just as much an abstraction as doing it on coding sheets - the fact that it is being written "on a computer" isn't directly relevant to code quality (it can just be written much faster with fewer trivial errors and without all that consulting of paper manuals).
In the early days of microcontroller assembler I used to write assembly language in French squared exercise books because I could see far more lines at a time than I could on a green screen monitor and it was quicker than using an ASR-300. Nowadays, of course, that would be impossible (and pointless).
"It's perhaps interesting to ask whether the coding sheets method actually made for better programmers"
Coding sheets weren't used by choice. They were used because the equipment for getting code into a computer used to be expensive and so everyone submitted their code to the punch department (always called "punch girls" because I never saw a bloke doing data entry) where it would be converted to card or paper tape, verified by punching it again in a special machine before it was sent into the computer room to be run, spooled or whatever variety of input process your mainframe used.
In the late 70s I worked an ICL site that had one VT for a department of a dozen programming staff. At one point the waiting list to use it was three days long.
When we converted to Sperry and got a bank of eight VDUs, and later, one each, we were gobsmacked. Turns out our pointy-haired manager didn't think we "needed" more on the ICL kit.
They replaced him for the Sperry kit-out.
I know they weren't used by choice, but because I/O was very expensive. That wasn't my question. The question is whether it was good training in accuracy to have to do it that way.
Watching some programmers bash code in nowadays, they are either geniuses or doing things in the most "obvious" way without really stopping to think. Some people still use paper a lot for initial thinking. Is there a best or optimal approach?
Some of us coded in red or blue ink. Not only was it good discipline, the keypunchers could read it more easily than pencil, so we got fewer errors. Then we read the cards, of course, before submitting them for compile. The idea was to get it to run the first time without compilation errors, and preferably correctly.
Also, we all had copies of punched cards showing all the default stuff, and when more than one program needed the same file structures, copies of those as well. We did not have to recode all that. Of course, later there were copy libraries, but that had to wait until we were using terminals rather than cards.
This post has been deleted by its author
"... the mainframe Cobol stuff focused on being rock solid rather than interesting; ask yourself if you want a more reliable air traffic control system or one that’s more exciting?"
Actually I'd like information on what air traffic control systems were written in COBOL. I'm sure they may be out there, but the ones I'm aware of were written in JOVIAL.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
