opinion: Who Bridges the Gap?

For well over ten years, technological advances have been opening up mainframes to the outside world. IBM knows that the mainframe must evolve to remain relevant in today’s computing environment, and that means that things have to change. Applications on Windows and UNIX need easy access to mainframe applications and data. Mainframe applications similarly need access to services from other systems, and in many cases need to be web-enabled.

IBM has also opened up the mainframe to non-mainframe developers with new languages such as Java and C/C++. Not only can IT graduates become productive quicker, but applications can be ported in from other systems to the mainframe.

What this means is that today there are two groups that work with the mainframe: those with traditional mainframe skills, and those with UNIX/Windows/Java based skills. This is where the problem is.

Mainframers and Distributeds

Let's take Application Programmers as an example. Traditional Application Programmers have skills in COBOL and PL/1. They edit their code in datasets using ISPF, compile them in batch, and are comfortable with application environments such as CICS and IMS. I'll call traditional mainframe staff Mainframers.

Distributed Application Programmers are experts in C and Java, and are at home with UNIX, J2EE environments, and Eclipse based development tools. Distributed Application Programmers today may be faced with projects accessing mainframe resources from UNIX/Windows, or projects requiring applications developed for and on the mainframe. I'll call those with UNIX/Windows/Java based skills Distributeds.

These two groups cover every aspect of mainframe development and support. Mainframe DBAs are faced with other systems accessing their data through facilities like ODBC, DB2 DRDA and IMS Open Database. Security Administrators have to contend with securing traditional applications and data from applications on other platforms, and even UNIX-based security for z/OS UNIX Systems Services. Even Operators aren’t immune: many are faced with monitoring UNIX and Windows servers as well as the mainframe.

You can see the problem can’t you: who bridges the gap between the two? We’ve all seen projects where a problem needed skills from both camps: Mainframe and Distributed. Example projects I’ve worked on include porting a UNIX C application to z/OS, commissioning a disk subsystem shared between z/OS and UNIX, and developing a Java exit for CICS Transaction Gateway.

So Who Spans the Gap?

Unfortunately, people willing to acquire both Mainframe and Distributed skills are rare. Many Mainframers are happy with their skill-set, and don’t want to take on the extra work needed to learn the new technologies. They also argue that they face a large enough challenge keeping up with their traditional skills as the mainframe continues to rapidly change. Distributeds find the mainframe perplexing, and want to stay as far away from it as possible.

This reluctance to learn the ‘other side’ creates another problem. Mainframers and Distributeds are often hesitant to even talk to each other as their age, background, skills, and even vocabulary are different.

So let's face some hard facts:

1. The need for skills that span both groups is not going to go away. It is going to increase.
2. C and Java are a lot easier to learn than COBOL and Assembler.
3. UNIX and Windows are a lot easier to learn than z/OS. Mainframers already have some expertise with UNIX and Windows.
4. Computing graduates come with years UNIX and Windows knowledge, and programming skills in C and Java. Almost none will have had exposure to any other system. Training them in traditional mainframe skills is hard.
5. Few computing graduates are interested in mainframes. Even if they find themselves in a mainframe-related project, the chances are that they will move on as soon as they can.

You can see where I'm going can't you? I strongly believe that it is up to us Mainframers to bridge this gap.

Why Us?

I may not be winning many Mainframer friends, but hear me out. I know that this means learning new skills. I know that the average Mainframer’s age is over 55. And I know that this means that Mainframers will have to treat 20-something year old Distributeds as equals; they know more about their area than you do.

But if you look at a Mainframer's job description, we’re already moving this way. Take networks as an example. How many SNA Systems Programmers are there? Close to none. It's all TCPIP. How about z/OS Systems Programmers? Today they must also be UNIX administrators, thanks to USS.

What's more, IBM is working hard to reduce the depth of mainframe knowledge needed to develop and support the mainframe. Think CICS Explorer, z/OS Health Checker and Rational Developer for System z as examples. This is only going to continue.

In many cases, Mainframers are being forced into the Distributed world as mainframes are centralised, outsourced, or replaced. From a group of seven Systems Programmers in my first job, I am the only one still in the mainframe game.

I'm not saying that traditional skills requirements are disappearing. However I believe that companies will de-skill in these traditional skills, and it's already happening. How many assembler programmers do you know? Or people who happily fire up IPCS and work their way through a dump? In the future, mainframe users needing these rarely-required mainframe skills will call in external consultants such as Longpela Expertise.

I'm also not saying that we should be doing all the work. Distributeds must also take the time to learn at least the basics about the mainframe world. A quick read of What On Earth is a Mainframe or something similar should be an absolute minimum.

But think of it this way. Mainframes are our platform. If we want to continue to work with them, then we must be willing to travel with them wherever they go. And they're going towards the distributed world.

The Way Forward

The good news is that these new skills aren’t that hard to learn. There's a huge range of material out there to get started. Want to learn Java? Get it running on your laptop. Grab a free J2EE environment such as Apache Tomcat if you need. Eclipse? There's a free version out there.

In fact, the chances are that there are opportunities with current mainframe projects to learn new skills. IMS Systems Programmer tasked with setting up IMS Connect? Take responsibility for IMS Connect, and anything accessing it. Setup capacity and performance monitoring, and investigate ways to get more from IMS Connect like the IMS SOAP Gateway. Write test programs that use IMS Connect, and see it through a Distributed Applications Programmer's eyes.

So if you're a Mainframer who wants to remain employed for the long-term, it's time to get out there and start learning.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.