How to prepare your IT staff for mainframe-to-Unix migration Pointers on communication, training, and mentoring By Chuck Musciano

April  1999

One of the most important, yet difficult -- not to mention overlooked -- elements in transitioning from mainframe to Unix environments isn't technical. It's the proper management of your IT staff. How can you ready your staff for the big changes that lie ahead and make sure it all goes as smoothly as possible? Chuck guides you through the most crucial aspects of the mainframe-to-Unix migration. (3,000 words)

Mail this article to a friend

hat's the most expensive item on your data center floor? That cool new robotic tape library? The 32-processor Enterprise 10000 server? The single-terabyte disk under the skin of that EMC storage array?

While all of this might be impressive to own (and pricey to acquire), its total cost doesn't come close to your most important and expensive resource: your system programmers and operators. The computers may crunch the numbers that run the business, but people run the computers. Without your dedicated and talented staff, nothing in that data center will run right.

Unfortunately, in the quest to move from mainframe systems to client-server computing, we often overlook the most important issue: preparing your staff to handle the many changes that will accompany that transition. This month and next, we'll take a step back from hardware and technology issues and deal with the people issues that surround the move from the mainframe to Unix.

Your most valuable resource
It's a regrettable fact that most systems folk are far more comfortable dealing with bits, bytes, and bandwidth than they are in handling personnel and employee issues. Hardware and software can be analyzed, compared, benchmarked, and engineered to provide the perfect solution to any problem. People, on the other hand, are unpredictable, nondeterministic, and difficult to understand. Unlike hardware, people can't be powered down and rebooted when things get sticky, and firmware upgrades are not available from the vendor.

In spite of these apparent drawbacks, your people are the most important component of your data center. If your shop is typical, you have individuals who have spent most of their lives in data processing. Many traditional mainframe support folks started out as tape operators and worked their way up to lead operators, system programmers, or data center managers. Along that career path, they dealt with countless systems problems, learned hundreds of ways to improve your environment, and installed technology that has bloomed, matured, and since fallen into obsolescence. Their historical knowledge of your systems and your business cannot be measured. More importantly, all that knowledge cannot simply be left by the wayside as you move from mainframe systems to newer Unix systems.

As you calculate the cost of converting your shop to new technology, don't ignore the significant cost of training and retaining your existing staff. While system configuration and design is fun and easy, don't let it distract you from mentoring and transitioning your staff to the new technology. Your existing staff are comfortable with their systems and will usually be suspicious of the "newfangled" systems you're deploying. You may also face generation gaps between your mainframe and Unix support groups. If you want your migration to Unix to succeed, you'll need to overcome these obstacles, and many more, to create a mainframe-class Unix computing shop.

Step one: Communication
This may sound simple, and it certainly has nothing to do with technology, but continuous communication with your support staff is the single most important thing you can do to ensure a successful conversion to Unix. Unfortunately, most people, especially computer geeks, aren't effective communicators. You'll have to overcome any misgivings you may have about delivering your message to your staff and begin a program of regular communication with all of your support people.

Keep in mind that most data center transitions occur over a period of years. The process is slow and incremental, usually involving one or two systems at a time. Eventually, what was once a mainframe-only data center is suddenly a "heterogeneous computing environment" with Unix, PC, and mainframe systems. Over time, the balance begins to tilt away from the mainframe to the newer systems until one day, you pull the plug on the mainframe and declare yourself converted.

The biggest mistake in keeping your staff informed is to delay discussing your transition plans until you're well into the heterogeneous phase of your conversion. By then, the glaring lack of information from management will force the staff to fill the void with rumors, erroneous information, and terrible predictions of layoffs, mass firings, and imminent disaster.

You can prevent all this negative PR with two simple steps: make sure you have a plan, and make sure you tell everyone what it is before you begin. Obviously, this puts the burden on you, especially the part about having a plan. If you don't have a plan for your data center transition, staff communication is only one of your worries. Sit down, figure out what you want, why you need it, how you'll get there, and who will be involved. Make sure management understands and accepts the plan. Having done that, you're prepared to keep your entire staff in the loop from the very beginning.

Most people are reluctant to share major transition plans early in the process for fear of disrupting the staff. It's true that many staff members will oppose the plan; others will be upset and may leave. But you're only digging yourself a bigger hole by trying to "sneak" a conversion past your team.

Instead, be up-front with your group. Explain the reasoning and goals of the conversion. Make sure they understand that they are a part of the project and are expected to step up and make it a success. Explain the potential for skills enhancement and the training opportunities that will be available. (You did plan for training and skills enhancement, didn't you?) By engaging your staff from the beginning and letting them know that you plan to support them throughout the transition, you eliminate much of the doubt and concern that surrounds any big change.

Step two: Training
Your mainframe staff has been trained to use the dozens of tools and systems that make up your mainframe environment. As we've seen over the past year, similar tools and systems exist for Unix. While the functionality of each of these tools has a mainframe equivalent, the user interface is usually quite different. A lot of training will be required to bring your mainframe staff up to speed on these new tools.

Fortunately, a lot of that training need only address user interface and usability issues. Once your staff realizes that your new Unix job scheduler does the same things as the mainframe scheduler, many of their job management skills will transfer seamlessly. The same applies to many other tools: backups, printing, security, and user management are fundamentally the same in both environments, but the tools are markedly different. Many operators will simply need to translate the old tool skills to the new tool, and they'll be back up and running.

Many members of your staff won't believe this transition of skills can occur. Mainframers are likely to believe they can't make the jump to Unix, for a variety of reasons. Often, training helps them understand that Unix and mainframe environments are more similar than different, and that they can be as successful in the Unix environment as they were in the mainframe world.

This same kind of skills equivalence is true for your system programmers, but more training may be required to help them make the transition. System programmers, by definition, deal with the intricate commands and obscure configuration parameters that keep a system running perfectly. You cannot learn all the tricks for Unix overnight, but you can learn how Unix works and start the slow migration from the mainframe world to Unix. It takes years to build system intuition -- the system programmer's ability to magically find the root of a problem by just thinking hard for a bit and poking around here and there. System intuition combines years of experience and thousands of solved problems to solve new problems in the least obvious ways.

Training can't create system intuition. Only hard-earned experience can give system programmers that magic quality that makes them gurus. This isn't to say that your system programmers can't make the leap to a new system. To the contrary, once they've proven their worth on the mainframe, they can do so again in Unix. You just need to be patient as they work their way back up to speed, and you need to hire Unix administrators to help them learn.

Step three: Mentoring
That brings us to the next important step: mentoring and coaching. Once your staff is trained on the new technology, you must create mentor relationships, so that your Unix gurus can teach the mainframers how to really run a Unix shop. The amazing part of this step is that the Unix folks will learn a huge amount about real production computing discipline.

In many shops there is a good-natured bickering between mainframers and Unix geeks. To the mainframe people, Unix admins are undisciplined and unappreciative of the true value of a mainframe system. To the Unix crowd, mainframe system programmers are set in their ways and hindered by old, inflexible technology. As you execute your conversion plan, these feelings can become ugly as the mainframers feel that their jobs are threatened by the Unix crowd. The Unix group may ignore the mainframe team, thinking that those people are on their way out anyway.

As we've seen in my previous mainframe-Unix articles, both groups have plenty to learn from each other. Mainframers need to understand the architecture and philosophy of Unix; Unix admins need to understand how discipline and procedures help create bulletproof computing environments. You can encourage the transfer of skills between the two groups by setting up mentoring relationships.

Mentoring can occur at both the operator and administrator levels. You might keep the process low-key, with mixed teams of support personnel assigned to run both Unix and mainframe systems. You could make it more formal by assigning staff members to tutor each other. How you build a mentoring program depends on what your staff needs and is willing to try. The important part is that you get these two groups working together on a daily basis.

Once you throw mainframe and Unix people together, you'll be surprised at the results. Mainframe people get excited by the new opportunities and leading-edge technology offered by Unix. Unix people realize that mainframers are hackers, too, with different tools and systems. Both groups realize that their systems are more similar than different, and their natural desire to learn and tinker with new things overcomes their reticence toward unfamiliar technology. With any luck, mainframe discipline will rub off on the Unix admins, and the mainframe group will begin to adapt their ways to the world of Unix.

Mentoring isn't easy, and it isn't a cure for everything. You must be prepared to coach your staff on helping each other and functioning well as a team. They must understand that the success of the transition depends on everyone, and that if Unix fails, the whole group fails. My old data center manager put it this way when the MVS and Unix support groups were combined: "It's as if Unix and MVS are playing a football game, and MVS is winning 49-0. From here on out, only Unix gets to score, and if Unix doesn't win the game, everyone loses."

Dealing with dissension
Trust me, communication and mentoring aren't going to magically make your personnel issues go away. From the very start, you'll have to deal with negative attitudes, complaining, and unforeseen problems. As you handle these problems, never forget that they're caused not by bad people, but by good people reacting badly to the pressures of change.

Some of the typical complaints you'll hear as you effect a transition to Unix from the mainframe world will include:

Unix is too slow
This is a classic complaint from the mainframe crowd, who can't believe that a little Unix server could possibly outperform their mainframe. No amount of discussion will convince them otherwise, so your only hope is to prove it with benchmarks after the systems are installed. Keep in mind that this is a valid complaint: If you don't architect your new systems correctly, they won't outperform the mainframe.

Another way to beat this complaint is to assign the task of Unix system tuning to the biggest mainframe defenders. Make sure you add a good Unix admin as a mentor, and you may find that your naysayers will happily prove themselves wrong. I am reminded of my very first programming job on a team of compiler writers. I discovered dozens of bugs in the compiler, which I dutifully documented and gave to my boss. He thanked me for my efforts, handed me the stack of reports, and told me to fix them all.

Unix tools are inferior
I've been trying to prove this one wrong for a year, and you can make a good case for effective Unix tools by bringing in vendors to demonstrate their wares for your staff. Site visits to more mature Unix shops will also help, as will training and experience with the new tools. This kind of complaint is a natural response from anyone fearful of change, so the best way to deal with it is to provide a level of comfort with the new tools you're bringing in.

As Unix people know, Unix is a toolsmith's dream world. Train your mainframe people on Perl, the shell, and the host of wonderful Unix tools like awk, sed, and grep, and cut them loose to create the tools they think are missing. They'll learn a lot about Unix, and you'll get some handy utilities to help run your systems.

I'm too old
Regrettably, this may be an inescapable problem for some on your staff. When presented with a systems transition, younger staff members will realize that they must transition to new technology to ensure their employment in the future. Older staff members approaching retirement may balk at learning a new environment and will instead plan to retire or leave the company when the mainframe is shut down. Still others will simply leave and go to companies that intend to run mainframes for a longer period of time.

You can't avoid loss of staff due to career decisions. Instead, make it plain to the staff that if they don't want to be part of the transition, they need to find jobs elsewhere. You aren't trying to run good people away, but you want to be up-front about real opportunities for the future. It's better to spend your resources on staff members who are willing to stay and learn than it is to suffer with those who never plan to make the transition.

The mainframe is good enough
Well, that may be true, but if it were really the case, you wouldn't need to leave it behind for a new operating environment. Often, your support staff considers only the technical aspects of a system in deciding its merits. In planning your transition, you need to look at the overall business case. If a mainframe costs a half-million a year in licensing and support fees to run, switching to lower-cost Unix servers makes sense even if they aren't quite as capable as the mainframe, but your bottom line is healthier as a result.

It may also be the case that the mainframe is perfect for the current application load you're running, but unfit to handle new apps you'll be implementing in a few years. Again, good communication can help your staff understand the reasons for a transition.

Making the transition
Converting to Unix from a mainframe is expensive, time consuming, and hard. Don't let people problems add to your worries. Have a solid plan, communicate it well, and get your staff working as a team towards the common goal of a successful transition. Be open, understanding, and supportive as your staff comes to grips with the changes in store. You'll find that you can turn potential problems into assets as you move forward in your migration to Unix.

If you thought dealing with staff issues was difficult, wait until you hear the howls from your customer base. Next month, we'll cover the other side of the human factor: your users.

Resources

• "How to manage and implement change in your Unix environment" (March 1999)
  http://www.sunworld.com/swol-03-1999/swol-03-change.html
• "Printing in the future: What are the alternatives?" (February 1999)
  http://www.sunworld.com/swol-02-1999/swol-02-print2.html
• "Can you get Unix print services on par with mainframe print management?" (January 1999)
  http://www.sunworld.com/swol-01-1999/swol-01-print.html
• "Unix tape services: Get on track" (December 1998)
  http://www.sunworld.com/swol-12-1998/swol-12-tapemanage.html
• "Cost recovery in the Unix world, Part 2" (November 1998)
  http://www.sunworld.com/swol-11-1998/swol-11-cost2.html
• "Cost recovery in the Unix world, Part 1" (October 1998)
  http://www.sunworld.com/swol-10-1998/swol-10-cost.html
• "Network or nightmare?" (September 1998)
  http://www.sunworld.com/swol-09-1998/swol-09-network.html
• "The job scheduling juggle" (July 1998)
  http://www.sunworld.com/swol-07-1998/swol-07-scheduling.html
• "How do you manage systems growth?" (June 1998)
  http://www.sunworld.com/swol-06-1998/swol-06-capacity.html
• "When disaster strikes will you be ready?" (May 1998)
  http://www.sunworld.com/swol-05-1998/swol-05-recovery.html
• "Battening down the hatches" (April 1998)
  http://www.sunworld.com/swol-04-1998/swol-04-unixsecurity.html
• "Is mainframe-class availability possible in a Unix environment?" (March 1998)
  http://www.sunworld.com/swol-03-1998/swol-03-24x7.html
• "Can mainframers and Unix die hards get along?" (February 1998)
  http://www.sunworld.com/swol-02-1998/swol-02-mainunix.html

• Chuck Musciano's past Webmaster columns
  http://www.sunworld.com/common/swol-backissues-columns.html#webmaster
• The SunWorld Topical Index -- a comprehensive listing of all SunWorld articles by subject
  http://www.sunworld.com/common/swol-siteindex.html
• Visit sunWHERE -- launchpad to hundreds of online resources for Sun users
  http://www.sunworld.com/sunwhere.html
• Explore SunWorld's back issues
  http://www.sunworld.com/common/swol-backissues.html
• IDG.net, your one-stop IT resource
  http://www.idg.net

About the author
Chuck Musciano started out as a compiler writer on a mainframe system before shifting to an R&D job in a Unix environment. He combined both environments when he helped build Harris Corporation's Corporate Unix Data Center, a mainframe-class computing environment running all-Unix systems. Along the way, he spent a lot of time tinkering on the Internet and authored the best-selling HTML: The Definitive Guide. He is now the chief information officer for the American Kennel Club in Raleigh, NC, actively engaged in moving the AKC from its existing mainframe systems to an all-Unix computing environment.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-04-1999/swol-04-careermanagement.html
Last modified: