There are good news and bad news in the world of NonStop Operation support.

First the good news: NonStop operation support teams have always been known to be one of the most technical and versatile groups in any enterprise environment. The team embodies a wealth of technical knowledge that is just as critical in ensuring the fault tolerance of the applications as the underlying NonStop hardware and Guardian operating system. They can diagnose and fix issues ranging from hardware, system software, application scheduling, database, network and others.

Now the bad news: Many members of that superb NonStop technical team are either retiring or looking to retire soon. What are you going to do to replace that talent pool? Is there a way to bring in new and younger resources to support your NonStop systems and applications to ensure it will continue to run smoothly?

I believe the answer is: "Yes." But it requires a new set of considerations.

"Set the right expectations"

Let's face it: Any new, young person you are hiring to learn the NonStop will never acquire the same level of knowledge as the retiring members. Why? Because most of the existing team members have accumulated their expertise through years (actually decades) of work experience. In fact, they have acquired knowledge for them to do work that usually require multiple people on other platforms like Windows or Unix to perform, e.g. Safeguard security (Security Department), Database and TMF (DBA), Web applications (eCommerce and Network team), Operating Systems (Architects), etc.

So, don't expect any incoming new hire to be able to step into those big shoes any time soon, if ever. This is an important point because that it clarifies the scope of what you are trying to accomplish with this new generation of team members. But that doesn't mean that the new team member couldn't be just as productive in many areas. It just requires some proper planning and commitments. First step is...

"Define the tasks that need to be done"

While some NonStop organizations have "Run Books" for operation, quite often, they are not maintained up to date. Even if they are, they represent only a subset of activities that NonStop Support team performs on a regular basis. Most NonStop shops will tell you that many NonStop operation activities revolve around dealing with things that come up unexpectedly. Ad hoc events like:

• "This application seems to be not responding..."

• "We got errors `out on EMS that we don't understand..."

• "That disk is very busy..."

These tasks actually require a lot of technical experience to address, and usually we take it for granted that the team knows from experience what steps to follow to analyze the problem. If we are to bring in new members to support Operations, it is important that the tasks be defined and procedures be "codified" properly.

I am not suggest that we go back and create volumes and volumes of run time documentation. But, I believe we should at least categorize the level of operation support work that needs to be performed, so that a new comer can learn to grow into that certain technical level incrementally.

As an example of a "Technical Ladder" could be:

• Level 1 - Basic operations to be functional on the system. Start and Stop jobs. Execute job streams.

• Level 2 - What to monitor on the system. Look for error messages. Follow standard recovery procedure.

• Level 3 - Handling problems. How to trouble shoot. Analyze performance issues.

There is no one size fits all, and every organization needs to define what fits their environment.

"Have a training plan"

Hint: Sending the new hire to standard NonStop Education class does not automatically fulfill your commitment to address this need.

In fact, I advocate that training the next generation of support team members on using the NonStop requires a whole new approach to training beyond standard HPE classes. I propose a new training paradigm that includes: Just-in-time training, Learning through analogies and Modern GUI tools. I hope to discuss these in a future blog installment.

What do you think? Please share your feedback. Thank you.

Phil Ly

TIC Software

I would also like to thank Mr. Jonathan Deveaux of comForte for reviewing and editing this blog.