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:
- The need for skills that span both groups is not going to go away. It is
going to increase.
- C and Java are a lot easier to learn than COBOL and Assembler.
- UNIX and Windows are a lot easier to learn than z/OS. Mainframers already
have some expertise with UNIX and Windows.
- 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.
- 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.
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
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.