Age is withering the mainframe's support

By Dave Bailey

19 Mar 2009

Comments: 10

A Computing logo
Dave Bailey

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.

Further reading

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.

Reader comments

COBOL is easy

if you want to add two fields together you say ADD FIELD1 TO FIELD2. COBOL has the most powerful case statement i've ever seen. you can make a decision table and write it straight into an EVALUATE statement. I wish I could find another COBOL job. some day when i retire, maybe they will still be around, i'll gladly write and maintain cobol

Posted by: John Smith  08 Dec 2010

Mainframe youngsters

Many keep saying the mainframes will be replaced, but looking at how integrated they are within large financial businesses and the complete lack of willingness to spend the money that would be required to convert to other platforms I'm very happy. Working within a large mainframe site knowing everyone else is around 20 years older than me and it fills me with confidence that in around 10 years time I will be an invaluable resource!!!

Posted by: Anon  27 Aug 2010

COBOL is remarkably easy to learn

Dirty little secret that it is at least an order of magnitude easier for a Java programmer to learn COBOL than the other way round. COBOL itself was designed to be easy. No pesky objects to putz around with. Everything is right out in the open and available. Much easier to develop in COBOL. So even if there were no COBOL programmers around, a Java or Ruby guy could pick it up rather quick. Now SQL and JCL is another story. Nothing like a JCL COND statement to run you aground.

Posted by: Baruch Atta  22 May 2009

Age Before Wisdom?

The smart move would be to port the legacy Cobol applications to a newer, more maintainable platform and then start on either a conversion of the code or an apprenticeship programme to re-train all the Comp Sci grads who seem to only know VB or Java. I'm the youngest formally trained Cobol programmer I know of that has done large amounts of Cobol programming and I'm pushing 50.

Since such a large proportion of the financial software world still relies on Cobol it seems now is the time to either start training or porting.

Posted by: TW Burger  29 Apr 2009

Mainframes and COBOL

The mainframe will probably survive for many years to come because it is better suited to handling large amounts of data than servers. As for COBOL, the problem is that it is no longer being taught, which means it will die when the persons who know it leave the workforce. I am 62 and have spent most of my professional career working on COBOL, but I am now working on Microsoft .Net. The majority of the current COBOL programmers are "baby boomers" in their 50's and early 60's. We are not ready to retire yet, and some of us may have to delay retirement, but within the next 10 years, many of us will be retiring. The person who said that the existing COBOL code will not need to be touched if they still work is extremely naive. Most changes to legacy systems do not involve bug fixes but changes to the requirements. Right now there is a glut in the market for COBOL programmers, but the situation will reverse itself as baby boomers retire. The choices are conversion of the remaining systems or training of new COBOL programmers.

Posted by: Philip Washburn  20 Apr 2009

Mainframe may not be dead, but the COBOL market still seems to be...

I have read other articles that profess a similiar belief about the "future" of COBOL and the mainframe in general.
At age 44, when I finished my last mainframe consulting job, I believed that I was well positioned to move into one of those jobs supporting all the code I had written over the 20 prior years.
I am 54 now, and as I have watched the market, nobody seems to need(want?) replacements for those retiring "crotchety geezers" you mentioned.
COBOL and the mainframe may not be dead, but I would guess a lot of experienced people might tend to disagree on its future, if the demise of experienced support staff is any indicator.

Posted by: Al Turner  13 Apr 2009

There is some hope

I am a student at Illinois State University and my major if Information Systems Intergeneration of Enterprise Systems. I have had programing class in java, COBOL, and JCL. The ECS program is new and is attracting students. IBM has provided massive support, and they understand that a new generation of mainframers needs to come into existence.

Posted by: Justin Provost  06 Apr 2009

COBOL is dead

Depends on how you perceive this statement.

TRUE - No jobs yet. For the past years we have been waiting for jobs - so COBOL has been dead for a long time.

FALSE - There a billions of lines in use today. But they don't need to be touched. If it works don't touch it.

My thought is overall COBOL is dead. Look at what people have been saying on this subject a pay attention to date of articles you read. The industry don't generally (only the odd few cases taken out of proportion) need COBOL skills as if they did they would advertise jobs with the term COBOL in it.

Or maybe there a just no COBOL jobs in LONDON.

http://www.reed.co.uk/job/searchresults.aspx?k=cobol&jto=false&s=&l=london&lp=&ms=From&mxs=To&st=5&ns=true&da=8630

Ah sorry found two here:

http://www.cwjobs.co.uk/JobSearch/Results.aspx?Keywords=cobol&Sort=2&LTxt=London%2c+South+East&Radius=0&LIds2=ZV

Anyway you see my point - when will the industry demand COBOL skills. Better start learning JCL and about CISAM quick 1000's of jobs are around the corner.

The more people do COBOL the less competition for the jobs that are in demand.

Posted by: Peter  05 Apr 2009

Is there a shortage of Vax skills yet?

I read that in a few years' time not only would there be a shortage of mainframe skills but that there would also be a shortage of people who could use popular mini computers from the same era such as the DEC Vax. I am eagerly awaiting a time when my Vax systems management and programming skills will make me rich.

Posted by: paul mayoh  23 Mar 2009

Three problems in one

Dave, you hit on a point that has been a growing topic of discussion at the IBM mainframe user's group called SHARE. Having just spoken on this topic at the group's meeting in Austin, Texas a few weeks ago, I can say that there are actually 3 areas of concern. One is diminishing skills, which can be addressed by in-house training or university partnership intiatives such as IBM's zNextGen. The tougher issues are mission-critical experience, that requires months of mentoring, and the loss of company domain knowledge - which can only be addressed by a comprehensive documentation initiative. Yet, sadly, many organizations are ignoring the problem altogether. My colleagues and I at Software AG believe this issue is so important that it should be included in an organization's disaster recovery and business continuity planning. Or perhaps the mainframe can just lay idle for a few days. Maybe no one will notice...

Posted by: Jim Fowler  19 Mar 2009

Have your say on this article

All fields required. Your email address will not be displayed on the site.

By submitting a comment you agree to abide by our Terms & Conditions

Technology Patent Wars

Large companies such as Microsoft, Facebook and Google have been hoovering up technology patents recently. Is this stifling innovation?

87 %

5 %

8 %