And then one day it is broke

Landed Underclass managed to push nearly all of my geek buttons this morning with his response to my COBOL post, eventually my dribbling rant grew so long that I moved it here as it seemed rather rude to stuff such a long rant into someone’s comments.

“Does Blind Steve really think that matters would be improved by rewriting all of this software in lavishly copy/pasted C++, and running it under Windows?”

Oh good god NO. Which is why I suggested that when the COBOL foundation stones do eventually crack it will probably constitute TWO disasters. Although I harbour a fondness for C that is common to my generation of programmers I have never thought that C++ was a suitable environment for coding systems at the sort of large enterprise mainframe level that COBOL excels at. C++ lacks all the things that make COBOL so robust.

The core C language is often described as combining the power or raw assembly language with the readability of raw assembly language. Bolting an object orientation paradigm (stolen from Smallatalk, which had a proper runtime environment) on to such a thing is like nitro charging a Vespa. It looks like fun, everyone will want one, all your friends will be really impressed, and sooner or later someone is going to get hurt real bad.

I have no doubt at all that the wide spread adoption of C++ in enterprise systems coupled with the sad demise of the mainframe have been the cause of much pain, no small amount of it mine.

“The language used to achieve this was called FORTRAN-IV.”

Arrgh! You picked a bad day to mention FORTRAN, and not because I don’t like it, FORTRAN is an excellent language, truly fit for purpose. (Unlike most of the code monkeys of my generation I am familiar with most everything back to Algol-60) .

No, it is because I am currently engaged in reverse engineering parts of a sophisticated program for which there is no source code, the core calculation engine of which was written in FORTRAN some years ago and compiled under MS-DOS.

Because it was written in FORTRAN by a proper engineer, it just worked, and worked so well that it was never replaced. Later, windows came along and not wanting to be left behind the original developers bought a Windows compatible FORTRAN compiler. They didn’t want to mess with their engineering code though, because it just worked, so they wrapped a thin graphical layer around it that made it output text to a window and left it at that.

Later still, someone else came along and decided that it would be nice to have a fully point and click GUI so that engineers using the program didn’t have to spend hours and hours constructing their input data sets, so out came the C++ compiler and the incarnation that I’m looking at was born.

At some point during the FORTRAN period some bugger did fiddle with the code, but only to add something else that you mentioned, something that I truly do hate, a dongle. And that’s the reason for my involvement. Because, as is always the case, the company that supplied the software went the way of all things, leaving my client with two very serious problems, firstly that the dongle in question is a parallel port device and parallel ports were obsoleted by USB. You can still by parallel I/O cards, but possibly not for much longer, and you can’t put them in a laptop. So the dongle has to go. Secondly, the software is time locked, and the clock is ticking.

To relate this back to my COBOL rant, what makes this such a dog of a job is the legacy baggage not of the FORTRAN language itself, but of the continual porting of the run time library without updating it. Since this dates way back to pre windows days, it does things in what are now decidedly non standard ways. It isn’t cooperating nicely with the operating system in the way that would had the code been taken out, polished, and recompiled even in a brand new FORTAN compiler. The run time library is obsolete and undocumented, etc, etc.

It aint broke, exactly, but I am still going to have to fix it. And this will be harder than it needs to be because over the years various otherwise sensible chaps have uttered the oh so reasonable sounding mantra “if it aint broke, don’t fix it!” and gone about their business. They have forgotten the words of the Master Programmer

Though a program be but three lines long,
someday it will have to be maintained.”

Same deal with all the silent running COBOL. IT departments have just ignored it on the basis that it aint broke. They’ve ported stuff forward without understanding it, they’ve never trained any of their staff to be maintainers, they no longer have the tools, or the source. What they should have been doing is gradually moving their code and skills base along with the times so at the very least they have one person in their department who owns and knows how to use a current COBOL compiler. But they didn’t, because it wasn’t broke.

Then one day it is broke. Chopping dongles off things I do for like, cheap, but enterprise COBOL hacking is a four figure day rate that will suck all the slack resources out of the average IT budget like a thirsty vampire on prom night.

Just because software doesn’t rust doesn’t mean it doesn’t need looking after.

Thus spake the master

Does a good farmer neglect a crop he has planted?
Does a good teacher overlook even the most humble student?
Does a good father allow a single child to starve?
Does a good programmer refuse to maintain his code?


Sooner or later, COBOL will kill us all

I read with some trepidation that the computer language COBOL (Short for COmmon Business Oriented Language) is fifty years old today.

“Why does this matter to me ?” I hear you cry. “I’m only here by accident, it is but a whistle-stop on my eternal quest to find play slime at wholesale prices .”

And well might you ask, for unless you share in the freemasonry of computer programming, it is unlikely that you’ve ever heard of COBOL. So a little background is required. Hold tight, I shall be mercifully brief.

To set the scene, COBOL was invented by the US military to make it easy for accountants to programme computers. But that is not the most frightening thing about it. It was initially specified during a really boring Pentagon meeting by US Admiral Grace Hopper. Notable for being one of the very few female computer geek icons. Foxy hard coding programmer of the Harvard Mk I, vaunted developer of the first compiler and fabled as the originator of the term “debugging“, she was a woman of exceptional talent and achievement known amongst her contemporaries as “Amazing Grace”.

It therefore remains a mystery to many computer programmers just why she chose to inflict such a Crawling Horror as COBOL upon the world. Presumably she was acting under orders.

COBOL is one of the canonical Bondage & Discipline Languages. From personal experience, it is unpleasant to create new programs with it and even more unpleasant to maintain old ones. While significant, this is not why we should worry about it.

What we should worry about are the following figures quoted at The Register and supplied by Microfocus, possibly the world’s only remaining COBOL vendor.

There are two hundred times as many Cobol transactions as there are Google searches every day, … in the UK we all use Cobol-powered applications ten times daily on average.

Anyone using a cashpoint or booking a holiday is probably also touching some of the two hundred billion lines of code in use (and counting).

The continuing popularity of Cobol can be attributed to the fact that it just works.

I can vouch for this personally. I can also vouch for the fact that some of that code is over thirty years old. Yeah, read that back, some of that computer code is over THIRTY YEARS old.

So yes, COBOL systems do tend to ‘just work’. COBOL grew up in the mainframe era, a golden age during which – although modern computer users would be surprised to hear it – computers were expected to ‘just work’.

But computer hardware doesn’t normally last thirty years. Many of the systems programmed originally in COBOL, the ones used by your bank, by your insurance company, by your credit card company, are now running in virtual machines, emulated on shiny brand new kit, their execution environments having migrated over the years as each new generation of hardware comes along. This means that they are now thirty years distant from their original environment, and thirty years distant from the media (tape or even punched card, I shit you not) that were used to originally load them.

A goodly number of such programs will have no source code, the human written and human readable set of instructions that define how they work. They consist only of extremely long sequences of binary numbers. This is bad. It is possible, but extremely difficult to reverse engineer binary code on any decent scale. Finding and fixing bugs in programs without source code is an expensive nightmare, and the skills to do it are genuinely rare. Worse, without source, and without applying massive reverse engineering resources, it impossible to say for certain what exactly a system is doing, or how it will respond to certain inputs, which makes recreating it in a modern incarnation much harder.

Even for the programs that have had their source code carefully preserved along with their operational environments there is a huge problem. I am 36 years old. I belong to the last generation of computer programmers who were taught COBOL, and even in that generation I was one of a scant few.

When the next Year 2000 happens, or when the systems succumb to bit-rot, hardware failure or disaster there may well be almost no one left who knows how speak the language in which they are written.

There may be none at all. Some of the systems are so robust that people don’t even know they’re there. They could already have exceeded the working life times of the last person within an organisation to know that they even exist.

Sooner or later there will be two horrible disasters. Firstly, some of the big COBOL programs will eventually break. Chaos will ensue. Secondly, those programs will have to be replaced. This task will be given to neophyte coders working for the lowest bidder. Chaos will ensue.

So, happy birthday COBOL. You are vile, and I hate you, but you are also ever living, mysterious, essential, and a valuable skill set. And Rear Admiral Grace Murray Hopper, Amazing Grace, we salute you. Ma’am.

So now, dear reader, you know our dirty secret. Large parts of the software eco system that sustains our critical infrastructure is written in a language that practically no one knows, almost no one can fix, and is effectively immortal.

May god have mercy on your soul.

I love the smell of breaking crypto in the morning…

… smells like, smells like, er, Red Bull.

Well, I mean it’s not the morning, and to be honest anything that yields so easily to a quick bit of frequency analysis and a cheeky bit of known plain text attacking is hardly fit to describe itself as ‘crypto’.

And it’s actually a supermarket brand generic energy drink.

But it progresses client work, and so here I am beating my geeky little code monkey chest into the void of cyberspace. Well hell, what else are blogs for ?

As we hax0rly types are wont to say, w00t!, pwned! and indeed my personal all time favourite, BWAHAHAHAHAHAHAHAAA.

%d bloggers like this: