Earlier this month, I was invited to an event where a select group of mainframe administrators and support chiefs from some big City firms were due to give a briefing on their mainframe operations.

I say “due” because unfortunately things didn’t turn out as planned. The briefing was to be held under the hush-hush veil of the Chatham House rule, which allows journalists to report what has been said, but not who said it or when.

However, the sensitivities of those in financial services appear, at present, to be so heightened by the economic turmoil that the event was called off just as I arrived outside the briefing room. Their nervousness was such that they could not even speak anonymously. From Chatham House to Bleak House in 10 minutes, you could say.

And that is a shame, as there would have been few better-placed people to shed light on one of the big mainframe issues of the day ­ the perception that a skills crisis is looming.

As many of you will know, all those crotchety geezers whom the business depends on to keep mainframes up and running seem to be reaching “end of life” ­ – or at least retirement age.

Anybody who heard When I’m 64 on The Beatles’ Sgt Peppers Lonely Hearts Club Band, might find the line “I could be handy mending a fuse, when your lights have gone” quite prescient with respect to mainframe administrators.

So what should an IT chief of a large enterprise do when their highly experienced mainframe administrators decides to retire? It’s unlikely that the mainframe is going to be retired at the same time. Because despite the prevailing wisdom that we should all be moving towards a distributed environment, the mainframe still has a strong appeal.

A single mainframe is much easier to maintain and secure than masses of distributed servers, for example, and there are also advantages in the areas of energy efficiency and disaster recovery.

The mainframe today is a different beast from the ones that needed to be attended to by men in white coats, back in the 1960s and 1970s. For example, an IBM z10 Enterprise Class system could run many instances of Linux on its 64 n-way processors and maximum memory of 1.5TB.

The performance of one of these beasts is also in a different league to the mainframes that dominated the world in the age before minicomputers.

The trouble is, however, if one of these mainframes goes down for an extended period, the business it supports could be going down for a much more extended period ­ – permanently. So having the right staff on hand to sort any problems out ­ – and quickly – ­ is essential.

One option for an organisation faced with losing a veteran mainframe administrator may be to come up with the type of pay package that would make retirement less appealing – but that strategy cannot work forever.

And it’s not just losing administrators that IT leaders have to worry about ­ – what about the impending departure of those programmers who have written critical legacy applications in Cobol? Good luck with trying to find skilled replacements for those guys.

There is a widespread perception that Cobol is a dead language. It’s true that today nobody would start out afresh developing applications based on Cobol, but until enterprises can readily tap the skills needed to migrate legacy applications onto something a bit more supportable, such as Java or Linux, the need for Cobol expertise will persist.

That said, there seems to be little evidence that those currently embarking on computer science degrees are being given a grounding in Cobol, never mind mainframe systems analysis or operating system management. Perhaps they should be.

Thinking about it, given the depth of the problems facing mainframe operators, maybe I can understand why some of them are reluctant to answer questions about it.