Perspective: Plugging the mainframe brain drain

The mainframe is often viewed as a cobwebbed hunk of iron that's only good for housing legacy data. But in 2004, the year Big Iron turned 40, mainframe revenue actually grew by 44 percent compared with the year before.

In one important respect, the mainframe business is showing its age, as the people who know how to maintain these machines steadily join the ranks of the retired.

This marks a generational passing of the torch. In 1964, the popularity of the mainframe brought about a movement to train and educate engineers to become mainframe specialists. These engineers helped shape the next 20 years of IT innovation in corporations, as the mainframe became the IT environment for data and applications.

In a job market where downsizing and outsourcing are sadly familiar themes, here is an opportunity to reinvigorate the IT work force.

By the late 1980s, however, distributed systems began to push the mainframe into the background. Many mainframe specialists shifted into different--some might say sexier--jobs, while others simply retired.

These days, most computer science programs no longer offer comprehensive mainframe instruction. The absence of new blood comes as nearly 80 percent of the people who work in mainframe support are 50 years of age or older. With more than 70 percent of the world's digital information residing on the mainframe, companies are now hard-pressed to find skilled staff to support these critical systems.

In fact, more and more mainframe engineers are being called back into duty well past retirement age because of the knowledge they possess.

The bottom line: Without drastic measures, the mainframe and all the business-critical data it houses could someday become all but inaccessible. Here's what needs to happen to prevent that scenario from ever becoming real.

Stepping up to the plate
The fastest way to create a new crop of mainframe talent is for IT universities around the world to recommit to mainframe education by reinstating the appropriate curricula.

When I did a quick search on Monster.com a month ago, I turned up more than 3,000 open positions for mainframe specialists. In a job market where downsizing and outsourcing are sadly familiar themes, here is an opportunity to reinvigorate the IT work force.

Additionally, the mainframe community should band together to provide universities with the necessary technical and personnel resources. Groups such as CMG, Afcom, Share and others have the depth and breadth to help universities get such programs off the ground.

Moreover, companies like BMC Software, Computer Associates International, IBM and others must continue to build educational initiatives for mainframe talent before it is too late. Such programs could range from academic scholarships to the creation or expansion of internal mainframe mentoring programs to help foster new talent.

Another fact: Companies need to better understand how to compensate for diminishing mainframe skills. Systems that offer heterogeneous management across mixed environments can eliminate the complexities traditionally associated with managing the mainframe. That makes it possible to work across both mainframe and distributed environments, regardless of one's database knowledge.

But time is slipping away. We are at a critical junction, as mainframe talent is quickly disappearing. Converting data from these systems requires a significant amount of time and a substantial monetary commitment. Often, such conversion is just not a viable option.

The shortage of mainframe talent will only become more acute--unless something gets done immediately. Failing that, this one-time marvel is destined to become a relic, and all the data it houses will be lost, never to be recovered.

Biography
Bill Miller is general manager of mainframe management at BMC Software.

More Perspectives

mainframe workers treated like MEAT!

That's why no one with a brain works in the mainframe business. When you work in the mainframe end, the business guys, the marketing guys, the politicos are the SHOW. The DP are treated exactly like "displaced persons".

Most people don't realize how computer people were treated like bottom feeders for most of the history of computing.

[Theosophe74]

A developer's reaction

<sarcasm>

Uh oh. These proposed solutions would only address would-be developers. What is a developer that's already out in the workforce to do?

I know, I'll attend the next MainframeOne conference. Oops, that's Java.

Ok, I'll just start leveraging the latest toolsets out there, like Visual Studio .MAINFRAME. D'oh, that's .NET.

Someone better tell the IT industry that they're heading in the wrong technological direction, and fast!

</sarcasm>

Visual Studio .Mainframe... ?

"Ok, I'll just start leveraging the latest toolsets out there, like Visual Studio .MAINFRAME. D'oh, that's .NET."

That's not so far fetched...

http://www.microfocus.com/pressroom/releases/pr200504251400000.asp

Folks are already using non-mainframe development technology for mainframe deployment. It doesn't have to be all green screens and terminal emulators.

Part of the skills issue (paricularly with regard to new blood) comes from persisting cultural divides that simply do not need to be there - these days it's more about interoperability than development in isolation.

Conversion = mainframe future?

What exactly is this guy converting? I bet he is converting from mainframe to server-based applications! And THAT means educational institutions should produce more mainframe programmers?? Rather short-term ain't it?

"heterogeneous" is also telling. One of our main problems are managers who aren't really specialists in any IT area, but think they can manage all of it.

S'far as mainframe vs. server - it has been proved back in the 70s that centralized approach is better for mass data storage. Currently mainframes are being replaced (or are replaced) by hundreds, sometimes thousands of servers. But simpletons who only see 1 small and "easy to fix or replace" computer on their desk believe server is so much better. Not enough courses IMO. And the author doesn't seem to know this.

And the 3000 jobs - yeah, maybe true. But mainframe has many different specializations - sometimes with no overlap. Also traditionally different industries didn't cross-hire. Brokerage-Insurance-Banking, etc. I bet most of those jobs are either conversion or operators, and the rest are very specific - not exactly a happy picture.

Conversion = mainframe future?

I think you are wrong about industry only hiring within industry. I have been a mainframer for over 20 years. I have worked for a railway, an insurance company, a provincial ministry, a Bank, a service provider, and now a wholesaler.
I am not alone.

how hard can it be?

I have people knocking down my door to go work for them but none of them have anything to do with mainframes. I used a mainframe (IBM 3090) in college, it didn't seem that complicated. How hard can it be to learn some gimp language like COBOL or RPG when you're an expert in a variety of other languages?

I'm guessing that this "shortage" is only an illusion. If there were a shortage, the salaries for mainframe developers would skyrocket and everybody and their dog be training up on them. Then they would just outsource all those high-paying jobs to India or China.

EASY

It's real easy to write COBOL. It's harder to design, build & deliver robust, supportable, scalable, efficient, innovative applications, on schedule & on budget.

The reason I'm considering a career change after 25 years on the mainframe - companies keep getting rid of of people who can do the latter, and hiring people offshore who can do the former.

I spend no more than 20% of my time coding & testing code. But twice in the last 3 years, my job has gone offshore to people who can do little else apart from write & test code.

Then the recruiters will reject my resume if I don't include the latest trendy acronym - for something that I have been doing for a decade or more. J2EE expert recruiters have no more business recruiting mainframers than J2EE coders have coding COBOL. I've been training in J2EE & I KNOW how big the difference is.

It's the OS, not the languages

The languages are easy enough, but an operating system like MVS can be an intimidating beast. It doesn't even have a concept of files, and while it's very configurable, there are few default settings, so setting it up and maintaining it is a lot of work. It does have great security, which is part of its appeal.

Years ago I wrote a book about the basics of navigating mini and mainframe operating systems (see http://www.snee.com/bob/opsys.html), and since it went out of print and I made PDFs of the chapters available for free, the MVS chapter has been by far the most popular.

This is crap

There is no risk of "all of the data it houses will be lost", as if one day companies are going to wake up and not have anyone to maintain mainframes or migrate data from them to modern systems.

Companies are profit driven. A CFO couldn't care less if his data is housed on a mainframe or on a bunch of cassette tapes fed from a commodore 64. The bottom line is support costs and reliability. Once mainframe engineers get scarce to the point they are able to command unreasonable salaries, it will become cheaper to move the data than maintain the mainframe. At that point simple economics will win out and the data will be migrated.

Along these lines, once engineers become so scarce companies are scrambling to move their data, specialty companies will spring up and hire these engineers and offer data migration services (I'm sure this is happening already). It's called a free market economy. If there's a niche someone out there will fill it.

Berating colleges for not offering mainframe curriculums is not the answer. Guess what? Colleges are businesses too, and if the cost of providing a curriculum outweighs the tuition they receive that curriculum will be cut. Not only that, but as a student why should spend 4 years of my life learning a system that by anyone's standards is considered a dinosaur? What are my job prospects when I graduate? How about 10 years from now? Who in their right mind would rack up $40,000 is student loans to learn MAINFRAMES? I think this journalist needs to come join the rest of us in the REAL world, and stop waxing poetic about old legacy iron that companies are either too lazy or to cheap to replace.

Bill......SHHH - quiet now.

QUOTE "I think this journalist needs to come join the rest of us in the REAL world, and stop waxing poetic about old legacy iron that companies are either too lazy or to cheap to replace.".

Oops.

The mainframe is NOT going anywhere any time soon.

1. It's almost always faster.
2. It can often handle large databases better.
3. It's generally more secure.
4. Conversion would cost tens/hundres of millions of $, with no immediate gain for many large enterprises.
5. There's no need to convert in some caes, where the distributed application model does NOT apply.

Just because many (smaller) businesses now use distributed apps to replace manual processes, does NOT mean that many largeer mainframe processes need to be converted.

There ARE convserions happening, but they will be with us for decades to come. In the 1980's I worked on a site conversion from Sperry 1108 (DMS & FMS8) to IBM 3090 (IMS) it took 4 years & costs tens of millions - and that was a like-for-like conversion (no new functionality).

[charlie cooper]

He's a computer exec

Regarding your complaint, you should realize that Bill Miller is not a journalist. As per the bio that appears at the end of the column, Miller is general manager of mainframe management at BMC Software.

Gimme a break

Bill;

Is it April 1st again this year?

[furl12]

What a bunch of clueless comments

The number of absloutely clueless responses to this article pertty much tells you why there?s a problem ? people trained on PC networks haven?t the slightest concept of how mainframes work.

Somebody took a college course twenty years ago and thought it was simple? I took a DOS course in Basic twenty years ago and thought it was the most trivial college course I?d ever taken. Does that have *anything* to do with modern computing?

Numerous people talk about ?mainframe and servers.? Do you lot honestly not know that a mainframe *is* a server?

I?m reminded of the great classical musician who said how often he was impressed with modern musicians ? until they tried to play classical music. Then he realized how musically mediocre they really were.

I feel the same way about most distributed programmers. They seem bright enough ? until you start talking to them and realize that they lack the serious underpinnings of real computer developers.

My sympathies though are with the laid off mainframe programmer. No, there is absolutely no way you can learn mainframes unless you already work on them. And few to no companies are hiring entry level mainframe developers or administrators.

Mainframe evolution

Aside from the fact the that a mainframe simply does (some) things better than any other platform, there is something else to remember. Dinosaurs were an evolutionary dead end. Mainframes continue to evolve.

Unix System Services allows me to write a COBOL program, to run on the mainframe (Z-series), which will create files directly onto a Unix server - just an API within the program.

There's another API appearing now/soon that will allow COBOL programs, running on the mainframe to do database activities directly on Oracle tables.

DB2 is having this funny pissing contest with Oracle & sometimes it's behind, sometimes it catches up. But it almost always provides a comparable ability to Oracle - bearing in mind the superior performance & security of mainframe DB2.

Using JNDI & RPC calls or Websphere MQ Request/reply messaging processes etc. it is not hard to interact between a web service & a mainframe-based Service Domain. Bearing in mind that the mainframe kicks butt in terms of security & performace, burying business logic in the DB2 Stored Procedures is often the optimum solution.

In addition to all this, OO COBOL is now becoming a reality.

So - why SHOULDN'T mainframe Enterprise COBOL be part of the solution, for years to come. If it can't do something now, just wait a short time & ther's be a solution.

Did I mention that the mainframe is generally faster, more secure & better able to handle ultra-large databases ?

Deciding the Truly Best Way to Do It

I any industry (IT included) would grow much better if we all would honestly determine the best way to do each job. That means, first, knowing enough about all of the ways of doing a job. Without that no valid conparison can be made. No one said this would be easy; it also means that quick answers will be wrong almost all of the time. Which means you will have missed an opportunity for real saving, and will be quickly outdone. Being the best takes effort, and clear knowledgeable thought. There never have been any short cuts about being the best over time.

[frwytcat]

It's someone else problem

Let's be accurate about what Mr. Miller is talking about. He wants someone else to pay for the training for a pool of talent that he perceives as lacking.

He doesn't want to have to train the raw talent himself. And he probably also doesn't want to pay 'top dollar' for the older, well trained people that are available.

Training

I think that is an unfair statement.
It's not just Miller's problem, it's everybody's.
Training for any job (not just) IT, is a large problem/responsibility.
Engineering firms don't train engineers.
Law firms don't train lawyers.
They come out of University with some sort of degree to build their skills on.
We should not expect a similarily complex profession to be trained within a firm using IT.

It's way beyond that.

"He doesn't want to have to train the raw talent himself. And he probably also doesn't want to pay 'top dollar' for the older, well trained people that are available. "

CEO want as cheap as possible. Period. In the brokerage industry what is left on a mainframe is only there because the law requires a central repository or it's cheaper. There are no other reasons.

What does all this debate about which platform to use have to do with people?

It's not the platform, it's the methodolgy...

I have observed the client/server/PC developers making the same mistakes the mainframers make. They are just 20-30 doing it years later....

What mistakes?

No change control, no history, no concept of what it means to be "production", no ability to grasp the scope of MAINTENANCE that will be required as an ONGOING demand on their time or it's cost.

Mainframers can and do continue to repair and run 20 year old code. PC code is "replaced" wholesale, maybe with a new version, maybe with a completely different product.

Most mainframers can answer the question "what has changed" even over an extended period of time. PC software, particularly popular OS'es just "decompose", seemingly on their own.

What is the latest trend? Isn't to make everything web based? Isn't that just pushing the client to the point of a dumb terminal? Isn't this the centralized / distributed cycle all over again?

Like my old ties, everything comes back in style. Well, maybe not a trout tie...

[Bloggs of Blogs]

Abso-freaking-lutely...

...and I say that as a modern web app-type person.

Mistakes are mistakes, procedures are procedures. Lack of
foresight, planning, and execution are standard pitfalls in many
an endeavor. To think the "technology" makes a difference is
short-sighted.

My biggest concern is that these mainframes represent millions
of hours of effort. To toss them out and replace them with
trendy "new" technologies (as if anything could really be
considered old, or new, in a field barely 60 years old) means all
the refinements and business logic detail embedded therein--
documented or undocumented--gets tossed on the scrapheap.

It's idiotic, but then again, that's modern life.

Why the author is totally mistaken.

The economy will always run on supply and demand. For every mainframe programmer in America out of work (thousands in NYC) there are over one hundred replacements overseas that will do the job for $5000/year or less. CEO's have no concern about quality until the total absence of it becomes a financial issue for them. This is what is taught in business schools and this is what the global economy is like. In a global economy every job that can be done elsewhere will leave. Pandora's box is open, and the door has been blown off it's hinges.

I can not wait to exit the IT world of eternal job uncertainty. As for finding experienced people, companies in NYC only want people with recent experience (a year or less out of work), as if doing the same job for 20 years experience simply evaporates into the air never to be found again. What ever happened to the old saying about riding a bike? They also want people with less experience, a PC way of saying they won't pay.

Of course there are exceptions to the laws of supply and demand. What the author suggest might have happened in a totally normal supply and demand environment, like the US used to be. For the remaining mainframe jobs in the country the corporations will lobby that they can't find programmers to do the job, and H1-B's will fill those slots. Of course the fact that H1B's are a form of corporate tax evasion really doesn't enter the picture, right? Please.

A. Theocharis
Poughkeepsie NY

IBM, it seems, does not support learning about mainframes

I've wondered if IBM actually wants mainframes to die.

From what I can tell, there is no reasonable way for a person to learn about mainframes apart from enrolling in significantly expensive courses.

Currently, the only reasonable way is to get copies of severely backdated versions of various operating systems and run them on an emulator, such as Hercules. IBM has no obvious program in place for those who might want to learn the technology.

If IBM wants mainframe technology to survive, they should provide a way for people to learn how it works.

The Mainframe Drain

EDUCATION!

Why doesnt Big Blue join forces with its partners and initiate the biggest push ever, at any educational outlet?

SCHOLARSHIPS? APPRENTICES?

APPLICATIONS? Why is there is no 'canned' software that runs on S/390 or AS/400?

Excel for S/390? Why not? Excel for AS/400? Why not? Pay me - I gladly develop the code!



I could go on, but it seems that

[Mollycoodle]

Good morning
This regards the old sperry Mainframe System that was situated in Wanganui New Zealand, this was decommissioned just a few years back, anyone who may have worked on this system, or who can verify it's capabilitys. would please contact me. [e-mail].

Thank you